directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [Version Numbering scheme] was: Version numbering and roadmap planning
Date Tue, 08 May 2007 13:52:04 GMT
OK cool.  Perhaps others can sound off on this approach?

Alex

On 5/8/07, Chris Custine <chris.custine@gmail.com> wrote:
>
> 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