Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make new release #290

Open
corneliusroemer opened this issue Jul 11, 2024 · 5 comments
Open

Make new release #290

corneliusroemer opened this issue Jul 11, 2024 · 5 comments

Comments

@corneliusroemer
Copy link

It would be amazing if you could make another release now officially supporting osx-arm64

I'd be happy to test a release candidate

@pablodelara
Copy link
Contributor

Hi @corneliusroemer. We are planning a release on the first quarter of next year. We don't have enough resources to do more frequent releases.

@ShamrockLee
Copy link

ShamrockLee commented Oct 24, 2024

Here are my two cents as a package maintainer of the Nixpkgs project.

I recently found that updating isa-l to dbaf284 solves the build failure of isa-l and its reverse dependencies on the Aarch64 macOS platforms (NixOS/nixpkgs#350167). As XRootD recently started to depend on isa-l, such an update is necessary to keep CERN ROOT available for particle physicists using Mac M1/M2.

An official release would be helpful to software packaging projects like Nixpkgs, as release tags are often more accessible than a pre-releasing revision. I've heard that some other packaging projects discourage packaging against an unstable upstream version. Still, I understand that making an official release is not just about adding a Git tag but implies much more effort and further support.

Thank you for maintaining such a great project, and I'm looking forward to the new release!

@rhpvorderman
Copy link
Contributor

I have a branch with 2.31 + just the mac fixes here: https://github.com/rhpvorderman/isa-l/tree/macos-arm-patch

The conda-forge build also includes those patches.

@pablodelara
Copy link
Contributor

Thanks for your input,@ShamrockLee. Would adding a tag be somewhat useful at the moment? We are not in a position to make a release now.

@ShamrockLee
Copy link

ShamrockLee commented Nov 6, 2024

Thank you for replying!

Would adding a tag be somewhat helpful at the moment? We are not in a position to make a release now.

It would be helpful if the tag is in a similar format to other versions, like v2.32.0-<preXX/devXX/etc.> or v2.31.0-<...>.

Stable releases are often mapped to git tags.which means we would write something like (rev = "v${version}";)

stdenv.mkDerivation (finalAttrs: {
  pname = "isa-l";
  version = "2.31.0";

  src = fetchFromGitHub {
    owner = "intel";
    repo = "isa-l";
    rev = "v{finalAttrs.version}";
    hash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
  };

  ...;
})

As for unstable versions, the rev attributes are specified manually as the Git commit hash, and the version is defined as <nearest version before>-unstable-<commit date in ISO 8601>.

Although Nix's builtins.compareVersions might get confused by the suffix, this is generally a minor problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants