directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Custine" <chris.cust...@gmail.com>
Subject Re: [Version Numbering scheme] was: Version numbering and roadmap planning
Date Tue, 08 May 2007 13:11:27 GMT
>
> Oh btw will this impose any issues with OSGi versioning?  Just thought I'd
> ask that.  Don't know what happens with the beta/alpha designators.



No this won't be a problem...


On 5/8/07, Alex Karasulu <akarasulu@apache.org> wrote:
>
> Hiya Chris,
>
> On 5/7/07, Chris Custine <chris.custine@gmail.com> wrote:
> >
> > My main concern with all of the implied meaning in the release numbers
> > is that the users will not pay attention to it, and eventually get irritated
> > with it when they have an issue with a new feature and we tell them that
> > they probably shouldn't play with their shiny new toy in production.
>
>
> Yeah true.  This is not a good situation to be in.
>
> Last night it occured to me that maybe we have all overlooked an obvious
> > solution that could make everyone happy.  With the unstable feature releases
> > we are basically talking about a very formal beta testing phase.  So maybe
> > we should call these releases beta releases, but without any special meaning
> > embedded in the numbers.  So after a stable release of 1.6, why don't we
> > do the typical release branch for bugfixe releases like 1.6.1, work off
> > of the trunk for the next major release and do releases from trunk as
> > 1.7 beta 1, 1.7 beta 2, etc. until things are stable.  Or at least
> > something along these lines.  I think this will make much more sense to the
> > users and allows the Directory project to introduce new features in beta
> > releases without worry of tripping up any bleeding edge users using beta
> > releases.
>
>
> I think I like this.  So the alpha would be for feature releases that may
> be somewhat destabilized.  The beta would be for releases that are being
> stabilized or optimized before a stable release?
>
> What do others think?
>
> There are a couple of small drawbacks.  Even though I see other projects
> > doing it, we shouldn't release beta builds on the main maven repo, although
> > I am not sure this is a hard rule, I think it is a general practice not to
> > do it.
>
>
> Actually this is not an issue.  I think we can release beta's as long as
> it is an officially voted on release.  It just signifies that new features
> are introduced before stabilizing or hardening the server.
>
> However this leads back to the main argument that the special unstable
> > build numbers are misleading when deployed to maven repos because the user
> > may not realize what the build number means and could use it in a production
> > app.
>
>
> Well the beta marker as you suggest does explicitly give a signal to the
> user.  I like it.
>
> I hate to spend so much time on this type of subject,
>
>
> This is very good tho - you're helping us answer some critical questions.
>
> but I just want to make sure that the users see things clearly and that we
> > don't impose any special rules on them with released versions.  The beta
> > solution may not be the prettiest, but there is a lot of precedent with
> > other projects and vendor products out there and at least this way the users
> > know exactly what they are getting when they download and install  ;-)  So
> > consider this just another suggestion...
>
>
> This is a good suggestion really.  Oh btw will this impose any issues with
> OSGi versioning?  Just thought I'd ask that.  Don't know what happens with
> the beta/alpha designators.
>
> Alex
>

Mime
View raw message