Wanted to put in a suggestion. Users are constantly confused and asking questions about the FreeBSD version naming scheme, somehow not quite picking it up right, which is which, where to use it, etc. And though I know what it is, it still seems silly to me. Because we've got logical pointers _loosely_ correlating to formal repo tag and branch names. Worst case I've seen was when FreeBSD had 4, 5, 6 all in flux at once. STABLE and CURRENT could only point to two things and there were about 10 potential tags involved. Basically, I'm proposing FreeBSD should relegate the terms STABLE and CURRENT out to the marketing portion of the web team. You can't check them out of any repo as tags, 4 and 5 were 'stable' when 6 was 'current' and so on. CURRENT means nothing more than cvs HEAD or svn trunk or git <nonce>. So use those terms instead of leading people think they can check out 'CURRENT' or that it has some magical command line, config file or source properties. website: 'The latest snapshots from our FreeBSD-STABLE and FreeBSD-CURRENT branches are also available'... checking out those branch names gets you HEAD. There are references to 7-STABLE, 8-CURRENT and parhaps other bastardizations on a theme :-) in the handbook that are not valid tags. STABLE is pretty much the same way, only more confusing if more than one thing is 'stable'. Back in the 4/5/6 days it could have referred to any number of branches. And on the main page, we now have more buzzwords... 'production' and 'legacy'. In fact, I'd venture that the proper place for such words, CURRENT/STABLE/production/legacy, is only on the release/download/support related pages of the website, with little '->'s to the actual tag they imply. More importanly, with descriptions that say something like which trains are developed/supported when, for how long. ie: why the deserve such words to be applied to them. Anyone who has a need to refer to CURRENT/STABLE is obviously getting beyond the release iso's and into the cvs/svn/git level of things. So just use the right terms then. Encourage people to use proper tags and for reporting bugs and things. They could probably make it into uname somehow. RELENG_x_y_RELEASE RELENG_x_y [date/serial] RELENG_x [date/serial] HEAD/trunk [date/serial] uname: '7.2-STABLE #0 <date of compile>' isn't quite the same solid reference as RELENG_7 as of yesterdays code. Which is what it is, not the zero-eth 7.2 errata/security/stability commit. And maybe figure out a way that each commit bumps a serial counter in UPDATING or some stampfile or uname so people can report the serial. Or maybe use the git crypto hash thing. FreeBSD needs a crypto hash reference inside the primary source tree anyways, not just on the n steps removed iso's. I dunno, just seen year after year of these questions on the lists :) Thought I'd put at least something out there. Not meant to be a bikeshed or anything. More like something to be addressed by doc project or whatever.
On Sat, 15 Aug 2009 01:48:27 -0400 grarpamp <grarpamp@gmail.com> wrote:> Wanted to put in a suggestion. Users are constantly confused and > asking questions about the FreeBSD version naming scheme, somehow > not quite picking it up right, which is which, where to use it, > etc. > > And though I know what it is, it still seems silly to me. Because > we've got logical pointers _loosely_ correlating to formal repo tag > and branch names. Worst case I've seen was when FreeBSD had 4, 5, > 6 all in flux at once. STABLE and CURRENT could only point to two > things and there were about 10 potential tags involved. > > Basically, I'm proposing FreeBSD should relegate the terms STABLE > and CURRENT out to the marketing portion of the web team. You > can't check them out of any repo as tags, 4 and 5 were 'stable' when > 6 was 'current' and so on. > > CURRENT means nothing more than cvs HEAD or svn trunk or git <nonce>. > So use those terms instead of leading people think they can check > out 'CURRENT' or that it has some magical command line, config file > or source properties. website: 'The latest snapshots from our > FreeBSD-STABLE and FreeBSD-CURRENT branches are also available'... > checking out those branch names gets you HEAD. There are references > to 7-STABLE, 8-CURRENT and parhaps other bastardizations on a theme > :-) in the handbook that are not valid tags. > > STABLE is pretty much the same way, only more confusing if more > than one thing is 'stable'. Back in the 4/5/6 days it could have > referred to any number of branches. And on the main page, we now > have more buzzwords... 'production' and 'legacy'. In fact, I'd > venture that the proper place for such words, > CURRENT/STABLE/production/legacy, is only on the release/download/support > related pages of the website, with little '->'s to the actual tag > they imply. More importanly, with descriptions that say something > like which trains are developed/supported when, for how long. ie: > why the deserve such words to be applied to them. > > Anyone who has a need to refer to CURRENT/STABLE is obviously getting > beyond the release iso's and into the cvs/svn/git level of things. > So just use the right terms then. Encourage people to use proper > tags and for reporting bugs and things. They could probably make it > into uname somehow. > > RELENG_x_y_RELEASE > RELENG_x_y [date/serial] > RELENG_x [date/serial] > HEAD/trunk [date/serial] > > uname: '7.2-STABLE #0 <date of compile>' isn't quite the same solid > reference as RELENG_7 as of yesterdays code. Which is what it is, > not the zero-eth 7.2 errata/security/stability commit. > > And maybe figure out a way that each commit bumps a serial counter > in UPDATING or some stampfile or uname so people can report the > serial. Or maybe use the git crypto hash thing. FreeBSD needs a > crypto hash reference inside the primary source tree anyways, not > just on the n steps removed iso's. > > I dunno, just seen year after year of these questions on the lists :) > Thought I'd put at least something out there. Not meant to be a > bikeshed or anything. More like something to be addressed by doc > project or whatever. >Nice document. I believe a lot of people get confused by these situations due to a matter of not using CVS, SVN, etc... etc... and have never heard of tags and such before. While more people have heard of and used these in their own environment at one point and are not used to the scheme that FreeBSD uses. While at some point everyone should come across http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html not everyone has been pointed to it for reference. I feel this document states these very clearly and besides what else are you going to call the development trunk/tree for FreeBSD-STABLE & FreeBSD-CURRENT ? call them both trunk ?. This is really based upon a well defined method of development that is fairly easy to understand if pointed in the right direction. A key factor in the "what is RELENG_X" type of situation is a "Am I missing something ?, What branch am I running again ?, What branch should I pick ?" and a good answer to that is right in the handbook telling yo u what these are all about. -- Jason J. Hellenthal +1.616.403.8065 jasonh@DataIX.net
In message <d2e731a10908142248o6ee77e1ie89a62f3c0937324@mail.gmail.com>, grarpamp (grarpamp@gmail.com) wrote: [...]> > uname: '7.2-STABLE #0 <date of compile>' isn't quite the same solid > reference as RELENG_7 as of yesterdays code. Which is what it is, > not the zero-eth 7.2 errata/security/stability commit.If you use SVN the revision number is included in the output of uname -a and uname -v. Cheers, Nick. --
Hi,> STABLE and CURRENT could only point to two things and there were about > 10 potential tags involved.Tags... You say tags. Now, freebsd is an constantly evolving project. It's never finished. And when a branch is, it's EOL. It took me two minutes, back in 97 to get the grasp and at that time the security branch had yet to be introduced, before that I tracked 'stable'. Go figure. You know, that's the beauty of this project: it's 'nix, but different. I agree with you we should find a solution about all this name-bitching: let's encourage them to actualy READ the F. manual. Let's include it in the FAQ ! Or include some pointer in UPDATING for those that like to mess with source code. Or would you like to rename STABLE into UNSTABLE ? Or FIXED ? Or into the $next_upcoming_release_number-ALPHA ? Now that sounds appealing to newcomers.... not. I occaisionally run a STABLE box in production without any trouble, so it's name is what you get: great software, it's stable enough. We also inject new software releases into our ports collection. I never read anything about it's name scheme. Funny, but very relieving IMO. Cheers. Robert