Re: freebsd naming of releases

From: Erich Dollansky (oceanare_at_pacific.net.sg)
Date: 03/29/05

  • Next message: David Schultz: "Re: Heads up: gtar gone from base system" 
    Date: Tue, 29 Mar 2005 10:21:44 +0800
To: Andre Guibert de Bruet <andy@siliconlandmark.com>

    Hi,

    Andre Guibert de Bruet wrote:
    >
    > On Mon, 28 Mar 2005, Chris wrote:
    >
    >> After what happened with 5.x releases would it be a good idea to name
    >> current releases different. eg. 6.1-dev 6.2-dev onstead of
    >> 6.1-release.
    >>
    >> here is the reasoning behind my idea.
    >>
    >> When 5.1 and 5.2 were released many datacentres and individual users
    >> were using them as if they were standard releases probably because the
    >> FreeBSD docs say that they reccomend using releases in this order
    >> starting with most stable first.
    >> RELEASE
    >> STABLE
    >> CURRENT
    >>
    >> Now of course 5.1-RELEASE had no STABLE phase so there was less
    >> testing but many users would not have known this and simply seen
    >> 5.1-RELEASE, I think this is how the mistake came about so many people
    >> were using 5.x before it was marked STABLE and the same will happen
    >> again for 6.x if the same naming convention is used. This would bring
    >> up a question such as which is more stable, 4.10-STABLE or 5.2-RELEASE
    >> since the latter is a RELEASE but the former is based on actual STABLE
    >> tree code whilst the latter is based on CURRENT tree code. I hope
    >> others can make sense of what I am saying. Please cc replies to me
    >> since im not subscribed to this list.
    >
    >
    > Here are things as I see them:
    >
    > With the 5.x series, we ran into an issue where we needed more
    > widespread testing of the branch before all of the bugs and edge cases
    > could be shaken out (And the eventual marking of the branch as
    > "STABLE"). 5-CURRENT took a number of years to develop, and no official
    > testing release was about for users to effectively test and give
    > feedback on [1] [2]. The notion that "CURRENT is not stable" worked
    > against the first release of the 5.x branch as some users were reluctant
    > to give the nightlies a try.
    >
    > The solution of marking the 5.[0-2] releases as "Technology Preview
    > Release" was very clever. It brought about testing on a whole slew of
    > hardware, and the much needed feedback that allowed the 5.3 release to
    > be the success that it was (At my workplace, we were so impressed by
    > 5.3's performance that we upgraded all of our 4.x servers to it).
    >
    > I believe it was Scott Long that sent out a roadmap that detailed the
    > way things were going to be done for the next set of releases. There is
    > a good amount of support behind the idea of releasing more often, and
    > not putting several years between major version bumps. This should of
    > course alleviate any doubt about how stable a .0 or .1 release really
    > is. Search the list archives for more details on this and the thread
    > that followed.
    >
    > Andy
    >
    > [1] The nightly iso images could do, but they are development releases,
    > with features being added here and there, and are generally not as well
    > suited for widespread testing as an official beta is.
    >
    > [2] The Developer Preview doesn't count either because features and
    > architectural changes were still being added/made at that point in time.
    > The introduction of these features brought about new edge cases and bugs.
    >
    I think he does not mean this. The process behind is fine. The terms
    used for it are confusing.

    It would be much easier for many users to understand terms like "alpha",
    "beta" or "production" as others to it. There is not other meaning in
    "release" as it is released but for what purpose?

    I know that there is some explanation for the terms at the site but why
    should terms be used which need an extra eplanation?

    Keep it simple.

    Erich
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: David Schultz: "Re: Heads up: gtar gone from base system"

    Relevant Pages

    • Re: best antispy program
      ... with time there are new features that is ... Some software providers are now releasing updates ... testing and call them beta updates. ...
      (microsoft.public.windowsxp.general)
    • Re: short beta for 2009
      ... But to make some happy for the moment they opened up beta to ... If they could just find the bugs that most didn't like ... The schedules were met, ... never quite finished many of the features. ...
      (comp.cad.solidworks)
    • Re: Delphi 2007 (HighLander) - Public Beta?
      ... new bugs or hide existing bugs in the current betas? ... features then you never will reach the release candidate stage. ... The same applies to a good beta program. ... sacred as the laws of God and there is not a force of law and public ...
      (borland.public.delphi.non-technical)
    • Re: Delphi 2007 (HighLander) - Public Beta?
      ... Beta versions come commonly, better said should come along with a feature freeze. ... other new features are introduced that also require testing to identify bugs to be fixed. ... Also I think introducing new features in the beta phase leads to much more banana software. ...
      (borland.public.delphi.non-technical)
    • Re: Publisher 2007 - New Version, Old Look
      ... Otherwise when the product was released, there would still be untested code full of bugs. ... Once the Publisher team were finished adding the new features, the beta was beginning, so they became busy fixing bugs found by beta testers and performing internal testing. ... Ed Bennett - MVP Microsoft Publisher ...
      (microsoft.public.publisher)