> It's not totally clear to me what the problem is here. In my > understanding, this would cause a dependency on a "beta" to be > upgraded to a dependency on GA. Given that the betas are either API > compatible or not intended to be used once the GA release is created, > it seems that this auto-upgrade behavior is more of a feature than a > bug. Sure, people's software could break, but IMHO, that's the danger > of using a pre-release package anyways.
Well, I have users that have found incompatibilities between beta and release, hence the (temporary) issue. > How do namespaces relate to versions? There will be a 3.0.1 release > coming up, potentially with a NuGet package. It's not clear to me > what the implications of that would be within the OpenWrap ecosystem. Namespaces hide certain versions, so if packages are in a "beta" namespace, and you don't import that namespace, the package won't be seen by default, hence avoiding the revision issue alltogether. That said, namespaces are not ready yet in openwrap, and I'm looking for a solution for my users for now that deals with the incompatibilities between the various debug versions. > As Fabio implied, it does seem strange that the "opinionated" > versioning in the package management system places a burden on every > library vendor. The packaging system should have a mechanism to > specify version numbers that can be transparently upgraded. Perhaps > even changes to the "build" number are okay for automated upgrades in > some packages. It's going to be an uphill battle to try to get > everyone to conform to a specific versioning scheme. Well, transparent upgrading is why we don't let people take dependencies on revision numbers, as it's expected that only bug fixing gets auto-upgraded through the revision. NuGet has version ranges but you have to add their own algorithm on top of that if you want to know if things will get upgraded or not. When packages exist in a package manager, I'm highlighting that it would be a good idea for those creating those packages to know what versioning entails, and be aware of the differences between the various solutions out there. If it is the case and you guys have made a conscious decision to auto- upgrade people between RC and GA, then that's fine. One cannot however imply that package management platforms should account for all versioning schemes that peopel come up with, the cost of maintaining this would be astronomical, don't you think? The issue I have right now is that because nuget is versioning ranges + algorithm and openwrap is versioning ranges + auto-update of revisions, there's different behavior for the usage of the revision tag, hence my suggestion that people get aware of those differences when pushing packages, and the early warning that we seem to be having a problem with versions right now.
