From Fedora Project Wiki
(Update notes with more info on caret.)
Line 6: Line 6:
 
* [[User:Tibbs/TildeCaretVersioning]] allows both tilde and caret versioning to keep Release: completely free of versioning information.  Caret versioning comes from https://github.com/rpm-software-management/rpm/pull/597.
 
* [[User:Tibbs/TildeCaretVersioning]] allows both tilde and caret versioning to keep Release: completely free of versioning information.  Caret versioning comes from https://github.com/rpm-software-management/rpm/pull/597.
  
Neither draft is as simple as the current guidelines but the second is a relatively small addition.  I don't know if either is more acceptable to anyone in particular.
+
Neither of the first two drafts is as simple as the current guidelines but the second is a relatively small addition.  I don't know if either is more acceptable to anyone in particular.
 +
The third draft, on the other hand, is a significant simplification.  It should hopefully make its way into RPM relatively soon, and should be backported to the live Fedora branches afterwards.  However, the question of RHEL will remain.  We can hope.
  
 
The fundamental issues I'm trying to solve:
 
The fundamental issues I'm trying to solve:
Line 15: Line 16:
 
* Keeping Release: simple is really appealing.
 
* Keeping Release: simple is really appealing.
  
With that in mind, here's the problem: these two simple, common cases are at odds with each other:
+
With that in mind, here's the problem: these two simple, common cases are at odds with each other if all we have is the tilde operator:
 
* Moving from a post-release snapshot to a new version.
 
* Moving from a post-release snapshot to a new version.
 
* Moving between upstream tagged prereleases and git snapshots.
 
* Moving between upstream tagged prereleases and git snapshots.
Line 27: Line 28:
 
* (1.2-1, 1.2-2.20180101.abcde, 1.2.1-1)
 
* (1.2-1, 1.2-2.20180101.abcde, 1.2.1-1)
 
Keeping Release: pristine sounds great, but....
 
Keeping Release: pristine sounds great, but....
* (1.2-1, 1.2+20180101.abcde, 1.2.1-1 + Epoch)
+
* (1.2-1, 1.2+20180101.abcde-1, 1.2.1-1 + Epoch)
Pushing snapshot information into release just gives us the current guidelines.
+
So that won't work.  Pushing snapshot information into release just gives us the current guidelines.
  
 
You can try to throw a tilde in there:
 
You can try to throw a tilde in there:
Line 34: Line 35:
 
It works in that case but sadly it breaks if 1.2a is released instead of 1.2.1.
 
It works in that case but sadly it breaks if 1.2a is released instead of 1.2.1.
  
So  it seems we have no choice but to keep putting post-release snapshot information into Release:.
+
So  it seems we have no choice but to keep putting post-release snapshot information into Release: or wait until we can use the caret operator.
 
 
If we had some magical operator '?' or something which compared like this: (1.2-1 < 1.2?20180101.abcde < 1.2.1-1) then life would be golden, but I don't think it exists.  All non alphanumerics besides '~' mean the same thing to RPM.
 
  
 
=== Moving between tagged prereleases and git snapshots ===
 
=== Moving between tagged prereleases and git snapshots ===
Line 61: Line 60:
 
* (1.2~1.20180101.abcde, 1.2~2.beta1)
 
* (1.2~1.20180101.abcde, 1.2~2.beta1)
 
Without the requirement for the digit on snapshots it "works" but is less pleasant:
 
Without the requirement for the digit on snapshots it "works" but is less pleasant:
* (1.2~20180101.abcde, 1.2~3.beta1)
+
* (1.2~20180101.abcde, 1.2~20180102.beta1) (increment the date)
An extra tilde kind of saves you:
+
An extra tilde kind of saves you, but.. meh:
 
* (1.2~~20180101.abcde, 1.2~beta1)
 
* (1.2~~20180101.abcde, 1.2~beta1)
 
With snapshot information in release, you can't add the beta1 tag anywhere.
 
With snapshot information in release, you can't add the beta1 tag anywhere.
 
* (1.2-1.20180101.abcde, ???)
 
* (1.2-1.20180101.abcde, ???)
 
+
Unless you use a tilde with nothing:
=== Conceptual issues with tilde ===
+
* (1.2~-1.20180101.abcde, 1.2~beta1-1
 
 
There are two main issues with tilde:
 
 
 
* It's one of a pair of operators, but we do not have its counterpart (shown as '^' below):
 
** 1.2 < 1.2.1~1 < 1.2.1~2 < 1.2.1 (X~Z is less than all possible X)
 
** 1.2 < 1.2^1 < 1.2^2 < 1.2.1 (X^Z is greater than X but less than all possible X.Y).
 
** See https://github.com/rpm-software-management/rpm/pull/88 and the newer https://github.com/rpm-software-management/rpm/pull/597 for an implementation of this.
 
* There may be a point where upstream has decided what to call the next release, but hasn't given you anything to put after the ~.  At this point it's actually fine to have nothing after the tilde, if that is actually something someone would need to do.
 
  
 
=== What to do? ===
 
=== What to do? ===
  
I see four options:
+
I see five options:
  
 
# Don't change anything.
 
# Don't change anything.
Line 85: Line 76:
 
# Allow tilde. Keep post-release snapshot information in Release:.  Keep prerelease snapshot information in Version.
 
# Allow tilde. Keep post-release snapshot information in Release:.  Keep prerelease snapshot information in Version.
 
# Allow tilde, with post-release info in Release and prerelease info in a place decided by whether you ever intend to package snapshots.
 
# Allow tilde, with post-release info in Release and prerelease info in a place decided by whether you ever intend to package snapshots.
 +
# Wait for the implementation of caret to be merged and pushed back to live Fedora branches.
  
 
Since people have declared that the first option is simply something they will ignore because they want tilde so much.
 
Since people have declared that the first option is simply something they will ignore because they want tilde so much.
Line 94: Line 86:
 
The fourth option is simply insane, but seems to be what the people who want tilde say because it appears they don't ever intend to package prerelease snapshots and don't care about that use case.
 
The fourth option is simply insane, but seems to be what the people who want tilde say because it appears they don't ever intend to package prerelease snapshots and don't care about that use case.
  
One thing is clear: allowing tilde does not simplify the guidelines.  It does make some specific versioning cases look nicer.  When you completely ignore the existence of snapshots, tilde certainly makes loads of sense.
+
The fifth option permits some really clean guidelines, but we have to wait a bit (maybe three weeks) and then EPEL cannot follow.
 +
 
 +
One thing is clear: allowing tilde by itself does not simplify the guidelines.  It does make some specific versioning cases look nicer.  When you completely ignore the existence of snapshots, tilde certainly makes loads of sense.  If we have both tilde and caret then things get significantly simplified.

Revision as of 20:58, 19 November 2018

Notes for the tilde versioning drafts

There are two drafts:

Neither of the first two drafts is as simple as the current guidelines but the second is a relatively small addition. I don't know if either is more acceptable to anyone in particular. The third draft, on the other hand, is a significant simplification. It should hopefully make its way into RPM relatively soon, and should be backported to the live Fedora branches afterwards. However, the question of RHEL will remain. We can hope.

The fundamental issues I'm trying to solve:

  • People really want to use tilde because for some (limited but common) cases it makes things simpler.
  • We need something which is relatively simple and "works" for the range of problems generally seen by people.
  • It would be nice to be prescriptive for weirder cases.
  • Keeping Release: simple is really appealing.

With that in mind, here's the problem: these two simple, common cases are at odds with each other if all we have is the tilde operator:

  • Moving from a post-release snapshot to a new version.
  • Moving between upstream tagged prereleases and git snapshots.

Moving between post-release snapshots and tagged releases

Take this version sequence:

  • (1.2, git snapshot, 1.2.1)

Current guidelines give:

  • (1.2-1, 1.2-2.20180101.abcde, 1.2.1-1)

Keeping Release: pristine sounds great, but....

  • (1.2-1, 1.2+20180101.abcde-1, 1.2.1-1 + Epoch)

So that won't work. Pushing snapshot information into release just gives us the current guidelines.

You can try to throw a tilde in there:

  • (1.2-1, 1.2+0~20180101.abcde-1, 1.2.1-1)

It works in that case but sadly it breaks if 1.2a is released instead of 1.2.1.

So it seems we have no choice but to keep putting post-release snapshot information into Release: or wait until we can use the caret operator.

Moving between tagged prereleases and git snapshots

Take this version sequence:

  • (1.2beta1, git snapshot, 1.2beta2, git snapshot, 1.2)

Current guidelines give:

  • (1.2-0.1.beta1, 1.2-0.2.20180101.abcde-1, 1.2-0.3.beta2, 1.2-0.3.20180102.fghij-1, 1.2-1) (0)

With keeping Release: pristine, you have to insert a digit and it's simplest to just start when you introduce a snapshot:

  • (1.2~beta1-1, 1.2~1.20180101.abcde-1, 1.2~2.beta2-1, 1.2~3.20180102.fghij-1, 1.2-1) (1)

Not inserting the digit until necessary does work, but seems easy to get wrong and hard to describe:

  • (1.2~beta1-1, 1.2~20180101.abcde-1, 1.2~3.beta2-1 ???, 1.2~4.20180102.fghij-1, 1.2-1) (2)

Pushing the snapshot information into Release gives:

  • (1.2~beta1-1, 1.2~beta1-2.20180101.abcde, 1.2~beta2-1, 1.2~beta2-2.20180102.fghij, 1.2-1) (3)

Now, to me none of these look absolutely terrible but it seems that #1 is the simplest that allows tilde. I'm calling the third one the "post-prerelease snapshot" option.

What if you knew upstream was going to put out 1.2 and package a snapshot, but then upstream releases a beta?

  • (1.2 git snapshot, 1.2beta1)

Current guidelines of course work fine:

  • (1.2-0.1.20180101.abcde, 1.2-0.2.beta1)

Keeping "pristine Release" with requiring the extra digit on snapshots works:

  • (1.2~1.20180101.abcde, 1.2~2.beta1)

Without the requirement for the digit on snapshots it "works" but is less pleasant:

  • (1.2~20180101.abcde, 1.2~20180102.beta1) (increment the date)

An extra tilde kind of saves you, but.. meh:

  • (1.2~~20180101.abcde, 1.2~beta1)

With snapshot information in release, you can't add the beta1 tag anywhere.

  • (1.2-1.20180101.abcde, ???)

Unless you use a tilde with nothing:

  • (1.2~-1.20180101.abcde, 1.2~beta1-1

What to do?

I see five options:

  1. Don't change anything.
  2. Allow tilde and keep snapshot information in Release:. Requires the odd "post-prerelease snapshot" thing if you ever go from a snapshot to a prerelease. Forbid the packaging of tagged prereleases if prerelease snapshots for the same version were packaged.
  3. Allow tilde. Keep post-release snapshot information in Release:. Keep prerelease snapshot information in Version.
  4. Allow tilde, with post-release info in Release and prerelease info in a place decided by whether you ever intend to package snapshots.
  5. Wait for the implementation of caret to be merged and pushed back to live Fedora branches.

Since people have declared that the first option is simply something they will ignore because they want tilde so much.

The second option just seems unreasonable.

The third option seems... inconsistent but at least possible to describe.

The fourth option is simply insane, but seems to be what the people who want tilde say because it appears they don't ever intend to package prerelease snapshots and don't care about that use case.

The fifth option permits some really clean guidelines, but we have to wait a bit (maybe three weeks) and then EPEL cannot follow.

One thing is clear: allowing tilde by itself does not simplify the guidelines. It does make some specific versioning cases look nicer. When you completely ignore the existence of snapshots, tilde certainly makes loads of sense. If we have both tilde and caret then things get significantly simplified.