search

chocolatey-archive / chocolatey

[DEPRECATED - https://github.com/chocolatey/choco] Chocolatey NuGet - Like apt-get, but for windows.
https://chocolatey.org
Apache License 2.0
2.8k stars 344 forks source link

Better versioning policy #330

Open TomOne opened 11 years ago

TomOne commented 11 years ago

I am not satisfied with the current NuGet/Chocolatey package versioning policy because of these points:

My favourite policy is the one from Ubuntu. It consists of the upstream version, the Debian revision, the word “ubuntu” and then the package version notation, e. g.: sudo-1.6.8p12-1ubuntu6 I think this version policy is the most flexible available and makes the distinction between upstream and package version perfectly noticeable.

Transferred to chocolatey it could be like this: imagemagick-6.8.6-9choco1.1 or firefox-23.0.1-choco2

rismoney commented 11 years ago

I am a big fan of http://semver.org/

TomOne commented 11 years ago

Yes, http://semver.org/ is nice, but it only refers to the versioning of an application itself, not the distiction between upstream and package version. Therefore it does not help here.

I like the epoch part in Debian package versioning. It’s a very good idea, because it allows a trouble-free continuation of the version, even when the version policy changes or when there was a mistake in versioning.

The versioning of Linux packages is a lot better than the one of NuGet. I regret that they have not taken a good example of them. It is not an easy task to change something fundamental like this later.

ferventcoder commented 10 years ago

imagemagick-6.8.6-1 would be what you were actually suggesting (I hope). If you read that, ubuntu packages are built on top of debian, so you already have the debian package version on there with -1 right before ubuntu6 (where six is the ubuntu package version).

I think ultimately we can find something more flexible. Along these lines I could see something like sometool.1.2.3-prereleaseinfo(1) or something like that. I am not a fan of that yet, just thinking out loud.

TomOne commented 10 years ago

I just don’t see any sensible reason why a package management system should force to mix together the version of the packaged software with package revisions without proper separator characters. In fact I don’t know any other package manager than NuGet/Chocolatey which forces maintainers to do this.

If for example a Chocolatey package has the version 1.10.3.20140327 I would naturally understand from it that it is also the version of the packaged software. Of course folks can learn that if the fourth segment is an ISO 8601 date, it is a package fix notation, but it is not obvious. Better would be 1.10.3-20140327, with a hyphen as separator (like used by Debian and Arch Linux), so that people understand that the part after a hyphen belongs to the package version fix notation.

The current restrictive versioning policy of NuGet/Chocolatey has also other issues:

Allowing only semver for package versions is not a good idea. Package managers must be more flexible to avoid these versioning issues.

ferventcoder commented 10 years ago

What if the software itself already uses four dot-separated segments for its version and you need to fix the package? If you have for example a software version 2.5.8.1, you are forced to alter the last segment, so the original software version information gets destroyed: 2.5.8.20140327. Then, for all the following packages of version 2.5.8.x, you are forced to use the current date as last segment, even if the affected package does not actually fix a previous package revision. You would have to wait until the packaged software gets released with version 2.5.9.x to be able to drop the date in the last segment and use the real software version again. So here an essential information is removed just because of a senseless restriction.

Actually you can get creative here. It's not suggested to do this in the fourth segment if it is used. Look at the ruby package. 1.9.3.392 becomes 1.9.3.39200 and the next release is 1.9.3.39201. It's not perfect and yes we should look at enhancing stuff like that. Where do you see this in terms of priority?

TomOne commented 10 years ago

@ferventcoder: Yes, but apart from distorting the original version information, the approach of modifying the already existent fourth segment doesn’t solve the problem of an accidentally misspelled first, second or third segment. I described that problem already in my previous comment (in the third list item). It happened to the Dropbox package: http://chocolatey.org/packages/dropbox/9.20. Fortunately there were only 8 downloads of the misspelled version.

It's not perfect and yes we should look at enhancing stuff like that. Where do you see this in terms of priority?

Of course Chocolatey also works with the current versioning scheme, but to become a robust and well established package management system, this is definitely an important issue to consider. I don’t want to blame the NuGet developers, but If I would build a package management system, I would never apply such a restricted and inflexible versioning policy. SemVer is nice for applications, but not appropriate for package versioning.

abombss commented 10 years ago

When we originally started using nuget to publish our own packages we tried to align the package version and content version numbers but quickly found the pain around this. Based on experience I think its best to keep package version numbers independent or at best just try to align the "Major" version numbers. SemVer is a good standard for package versions to easily handle compatibility of dependencies and upgrades, I don't think its mistake that nuget aligned to this scheme.

The missing link is nuget's inability to have custom metadata, while we could argue adding a "Content Version" field could help in these situations, the better solution would be extensible metadata so Chocolatey could handle this issue independent of the nuget team.

Adam

On Fri, Apr 11, 2014 at 5:22 PM, TomOne notifications@github.com wrote:

@ferventcoder https://github.com/ferventcoder: Yes, but apart from distorting the original version information, the approach of modifying the already existent fourth segment doesn't solve the problem of an accidentally misspelled first, second or third segment. I described that problem already in my previous comment (in the third list item). It happened to the Dropbox package: http://chocolatey.org/packages/dropbox/9.20. Fortunately there were only 8 downloads of the misspelled version.

It's not perfect and yes we should look at enhancing stuff like that. Where do you see this in terms of priority?

Of course Chocolatey also works with the current versioning scheme, but to become a robust and well established package management system, this is definitely an important issue to consider. I don't want to blame the NuGet developers, but If I would build a package management system, I would never apply such a restricted and inflexible versioning policy. SemVer is nice for applications, but not appropriate for package versioning.

Reply to this email directly or view it on GitHubhttps://github.com/chocolatey/chocolatey/issues/330#issuecomment-40259179 .

TomOne commented 10 years ago

@abombss, thanks for explaining your point of view.

My idea is just to look at how other popular package managers for operating systems are built and to learn from them. For example, consider the openssl package of other package managers:

As you can see, every single package manager in this list allows the original version notation of openssl (currently 1.0.1g) in the package version. In this way, an user immediately sees what version of openssl the package contains. I don’t think that this approach is bad as almost all package managers adopted it. The only “disadvantage” of this approach is that the versioning logic is a bit more complex. But in my opinion in this area a good user experience should have a higher priority than avoiding a little more program complexity. The creators and programmers of these other package managers seem to agree with me.

Or do you think it is better to be forced to version the openssl package with something like 1.0.1.20140411 like OpenSSL.Light from Chocolatey? I don’t think so.

A separate “content version” could be another approach, but that would also bring more complexity into Chocolatey and could also confuse users, because then there would be two version strings and the user must distinguish between them.

I don’t see any sensible reason why Chocolatey should not adopt proven patterns of other popular package managers. I remember to have read “Chocolatey NuGet - kind of like apt-get …” in the Chocolatey wiki. From this I understand that Chocolatey intends to learn from apt-get, otherwise it wouldn’t make sense to write this. :smiley:

jberezanski commented 10 years ago

I think I like the RPM versioning scheme best. The package version there consists of the full version number of packaged software, followed by a distinctly separated package revision number (an integer starting at 1). The third revision of openssl 1.0.1g would be named openssl-1.0.1g-3. That way the package can be fixed without artificially changing the packaged software version number, yet the system remains quite simple and does not present the user with two full-length, four-part version numbers.

One way to implement it on top of NuGet infrastructure could be perhaps to expose the packaged software version number to NuGet as the package version and keep the package revision as custom metadata used only by Chocolatey (and visible on the package details page in the gallery). For fixing a package, Chocolatey gallery should allow uploading a new package with the same NuGet-visible version number as the current one but increased revision. As a consequence, updating a package to fix/improve the install script would not prompt an update for users which already have that package installed - a good thing, IMO.

(To elaborate on the last point, an example: I installed MS SQL 2012 from a package, working around a bug in its chocolateyInstall. After I notified the package owner, he fixed the script and released an updated package. Now that package shows in cver as an available update, but one I do not need or want to install, since I already have a working SQL Server installed by the previous package revision. If the package version exposed to NuGet was the exact version of packaged software, I would not be offered an update - correct, since I do not need it.)