Brainstorming for RFC: pname and version

Development RFCs
81

Well, in the specific case of GCC, I think I have some merit. As I have seen on the official site, versions before 7 are officially deprecated, while versions at least 7 are maintained (with backports and all fluffs). If this is the case, how we should maintain all these versions concomitantly, at least for the corner cases of some softwares that depends on it?

82

Well, in the specific case of GCC, I think I have some merit. As I have seen on the official site, versions before 7 are officially deprecated, while versions at least 7 are maintained (with backports and all fluffs). If this is the case, how we should maintain all these versions concomitantly, at least for the corner cases of some softwares that depends on it?

Right now for backport-maintained branches we use the same pname and only specify version (but we have to specify the branch version in the attribute name, of course). Given that practice, I think a change requires stronger arguments than just having both in Nixpkgs at once (we have them now without modifying pname)

83

Well, it looks fine to me.

Now I need to think in what we can put as pname. E.g. pname=gcc is for the stable releases, while pname=gcc-master should be useful for the latest master code.

Also, it needs to reflect some other decisions, such as gcc-master-riscv if we build a RISCV-capable compiler.

(I am being a bit vague in order to abstract the things.)

84

Wait, what? This entire discussion was exactly about having same pname for official releases and snapshots with version carrying the details. (I guess lowPrio on snapshots could record the preference for releases).

I don’t really expect all configuration options to be included in pname, only the ones most affecting the scope and something «it is about a completely different binary/library this time». This riscv thing surely needs to be more about cross, right?

1 Like
85

I am doing some “exploration” about what should be put on those attributes.

Now, your suggestion is that version should carry info about the source code origin, while pname should be restricted to “only the ones most affecting the scope” &c?

86

Now, your suggestion is that version should carry info about the source code origin, while pname should be restricted to “only the ones most affecting the scope” &c?

I think this is the least change of practice, and compatible with having consistent guidelines.

87

That being said, we can think about how to encode the relevant information to version attribute.

The most habitual case is to catch the latest source code from the master branch.

We have two examples here:

  • After releasing a stable version, Zig updates the source code to reflect that the master branch will be tagged with a superior number. Nowadays, the stable code is 0.8 while master branch is 0.9:

Then, we can conclude that Zig master is considered by the upstream project as a new version, and not as a continuation of the previous stable version.

  • The other approach would be if the upstream propagates the stable version to the master branch; the most straightforward examples is MPV:

The latest tagged version is 0.33.1 while the source code is tagged 0.33.0

We have two paths to choose here:

  • Using Zig as example, version=0.9.0-pre+date=YYYY-MM-DD;

    It conveys the idea that the latest code is not coupled to the current stable release but to the future stable release, as @blaggacao suggested before.

  • Using MPV as example, version=0.33.0+date=YYYY-MM-DD;

I think we can adopt both approaches, according to the upstream project, or to impose some preference on the first approach (the Zig one).

88
  • After releasing a stable version, Zig updates the source code to reflect that the master branch will be tagged with a superior number. Nowadays, the stable code is 0.8 while master branch is 0.9:

The latest tagged version is 0.33.1 while the source code is tagged 0.33.0

We have two paths to choose here:

  • Using Zig as example, version=0.9.0-pre+date=YYYY-MM-DD;

  • Using MPV as example, version=0.33.0+date=YYYY-MM-DD;

I think we can adopt both approaches, according to the upstream project, or to impose some preference on the first approach (the Zig one).

That does the previous history tell us about MPV? That the current development will actually be 0.34? Do we expect the current development to actually include 0.33.1 fixes?

Because in a sense it is a bit confusing if 0.33.0+date is definitely newer than 0.33.1

89

In a certain sense, we Nix packagers are free to adopt a version number that does not necessarily reflect the upstream software we are packaging.

In a certain sense, both things occur in parallel. Zig did exactly this: the master branch points to a future version, but from that master it is possible to cherry-pick code for backporting. The 0.7.x series had a 0.7.1 release whilst the master pointed out to 0.8.0.

Therefore, I cast my vote on the “Zig way”: increment the stable tag and concat date=YYYY-MM-DD to it.

Because in a sense it is a bit confusing if 0.33.0+date is definitely newer than 0.33.1

That being said, 0.33.0 being the Stable, what we should use to indicate the future release?

  • 0.33.0.0+date=YYYY-MM-DD
  • 0.33.1+date=YYYY-MM-DD

The first option does not modify the stable version attribute, it merely concatenates a string to it. This can be useful to compose the version based on the stable upstream info.

90

In a certain sense, we Nix packagers are free to adopt a version number that does not necessarily reflect the upstream software we are packaging.

In principle yes. But presumably we have some goals. Hopefully these include minimising confusion.

Of course different factor of minimising confusion might contradict each other.

A transparent relation between our version and upstream version is a plus when it can be had


In a certain sense, both things occur in parallel. Zig did exactly this: the master branch points to a future version, but from that master it is possible to cherry-pick code for backporting. The 0.7.x series had a 0.7.1 release whilst the master pointed out to 0.8.0.

If they announce they are working towards 0.8.0, calling it 0.8.0-pre on our side does sound appealing


(Do we know of any upstream that has ever decreased the target version of new feature development, while keeping all the changes, not just creating a partial backport to stable? That could be annoying
)

  • 0.33.0.0+date=YYYY-MM-DD
  • 0.33.1+date=YYYY-MM-DD

The first option does not modify the stable version attribute, it merely concatenates a string to it. This can be useful to compose the version based on the stable upstream info.

Well, there is a partial order defined semantically «this snapshot includes all the changes from that snapshot», and there is a linear order defined syntactically by Nix version comparoson code. It would be definitely nice to have them compatible.


 to reduce confusion. But then we need to see when this is compatible with reasonable use of upstream versions, and how to describe the guidelines in a not-too-confusing way


91

Certainly. My point here is that, in case of dubiety, we can ponder our side more than the upstream.

I am of the idea we can ignore those things completely. We should not need to rely on these upstream decisions about their own development cycles, even because sometimes it requires digging the upstream source code, a task that we should not be required to do (besides not being a pleasurable task every time).

I prefer to use the tagged upstream release as a basis, trying to maintain it without modification, and appending the relevant info to it.

92

I am of the idea we can ignore those things completely. We should not need to rely on these upstream decisions about their own development cycles, even because sometimes it requires digging the upstream source code, a task that we should not be required to do (besides not being a pleasurable task every time).

I would say that both people packaging and people using unreleased snapshots of upstream software are more likely thna average to have a rough idea about the upstream development in terms of versioning and features included. If you cannot name how the snapshot is better than a release for your purposes (and cannot name a person who can and asked you for help), you probably won’t package it.

And if people packaging have some idea about features and fixes included, trying to align version comparisons with partial order of «includes same changes but also more» seems also valuable.

I don’t think mandating a thorough check whether the next version can be predicted is a good idea. I think that allowing it if it is well-known anyway might be good. I definitely think that the base version for unreleased-snapshot numbering should always be at least the largest upstream version number corresponding to a released snapshot containing a strict subset of the changes in the unreleased snapshot under consideration.

93

The idea is good. How can it be formalized? Allowing a different number schema based on additional knowledge about the upstream project?

94

The idea is good. How can it be formalized? Allowing a different number schema based on additional knowledge about the upstream project?

As we are going to package official release candidates as versions with «negative» suffix from the target versions, and as «almost as good as an RC» thing will intuitively get packaged in a similar way, I am indeed in favour of just allowing to use either a known «base version» or a «revealed» (it’s up to people working on the corresponding expression to decide what is clear enough) «target version».

95

After a long heck of time, I have read this issue in repology-updater.

It clarified some things to me, like this:

About this specifically, Repology suggests never use the future as a ground, but the present (or past if you think about it). Copy-pasting them:

The version of snapshot which comes after official 4.7 version may thus look like

  • 4.7postgit20170928 or 

    See how it’s better than:

  • 


  • 4.8pre20160928 (you are guessing which the next version would be, and you may be mistaken. For instance, it may be 4.7.1 which would make the version go backwards)

Indeed it was exactly what happened recently with Zig. They released a bigfix 0.8.1 version, while internally they point to 0.9.

1 Like
96

New release, with few modifications:

Now I plan to “github” this in one week or less.

97

Hm, branch is defined but not mentioned as a possible consideration for choosing the «base» snapshot. Is this intentional?

98

(apologies if already covered) Regarding the 0.0.0 default. With the punctuation change to unstable and the date, it shouldn’t be necessary anymore include the version in those cases.

name-0.0.0+unstable=2021-10-10
becomes
name+unstable=2021-10-10

which is very close to the current usage. It’s also a tiny bit clearer, because what if they in the future release a 0.0.0?

99

More or less. In the discussions above, the concept of branch was cited in the case of a team that uses multiple branches to different purposes, such as long-term-support and bleeding-edge.
But I don’t think it should be encoded in version; it looks something more akin to pname.
IMO, pname="fancyProgram-lts"; version="1.5.3"; looks more reasonable than pname="fancyProgram"; version="1.5.3+branch=lts";

My reason to maintain this terminology it is that it can be useful for future RFCs. The concept of branch is very pervasive, it is present even when not directly cited.
Indeed, in the previous wording of this pre-RFC, the “Unresolved Questions” explicitly employed it.

Nonetheless, I am open to evaluate arguments for erasing such unused terms.

100

More or less. In the discussions above, the concept of branch was cited in the case of a team that uses multiple branches to different purposes, such as long-term-support and bleeding-edge.
But I don’t think it should be encoded in version; it looks something more akin to pname.

I don’t think the branch should be encoded, but I think that the base version for an unreleased snapshot should be the last version in the same branch, if this is a relevant consideration. Just so that the advice makes sense for multi-branch cases like GCC.