On Sat, Jan 29, 2011 at 12:51 AM, SerialSeb <[email protected]> wrote:
> HI all,
>
> The nhibernate packages have been using the revision number to
> denotate alpha / beta / release status. This introduces
> incompatibilities in openwrap, as we let the revision be automatically
> updated silently and rely only on major.minor.build.
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.
> As such, temporarily I'm going to have to override the nuget packages
> on openwrap servers with custom versions that are going to be 3.0.2,
> 3.0.3 and 3.0.4 instead, and let people override their package
> versions themselves when they want a specific version. I'll also
> annotate 3.0.2 and 3.0.3 with a namespace, please let me knwo which
> one you'd want (pre/beta/rc/edge/whatever).
>
> Once we have pre/namesoace support, that problem will not happen as
> much, although OpenWrap do expect to have different version numbers
> across namespaces (beta/release can't have the same version number).
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.
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.
Patrick Earl
