On Fri, 02 Jul 2004 10:42:53 +0100 Dave wrote:
DS> Dave> R 5.1.1
DS> Dave> C 5.1.1+cvs 2004/06/01
DS>
DS> Wes> I don't think the reported version number as released by the tools
DS> Wes> should have anything other than things parsable by .s. IE, 5.1.1.cvs
DS>
DS> It would still leave the option of a format such as
DS>
DS> 5.1.2.cvs.2004/08/01
DS> or 5.1.2.cvs-2004/08/01
I'd like to recommend that we avoid path separators: eg '/', '\' and ':'.
DS> So I'd be inclined to [use] "5.2.cvs"
DS> and introduce a new version tag for the main development line.
DS> Something like "5.2.development" or "5.2.main" or similar.
I think if we are looking forward, we just need one tag.
DS> It looks as if the general preference is to distinguish "preN" and
DS> "preN+CVS" code - correct?
Sort of. I'd like to suggest that the version string for a release (x.y,
x.y.preN, etc) only exist for a brief moment in time, during the creation of a
release. As soon as a tarball is published, cvs is updated to indicate that it
is now development code.
While that does mean that, until a fix is checked in, there are two
different version strings (x.y, x.y.1) for exactly the same code. I don't
see a problem, since this is essentially how real cvs tags work. Making the
update to indicate dev status part of the release procedure reduces the chances
of someone checking in a fix and not remembering to change the string. It also
ensures that someone using cvs (or a cvs tarball) knows they've got a
development version (even if, for a moment in time, it is no different from a
released version).
Assuming an optimal (quick) release cycle:
1) There is a pre1, in which only a few bugs are found
2) There is a fc1, in which no show-stopper bugs are found
Here's an example of what I'd like to see for the 5.2. release line:
Event version
------------------------ -------------------------------
coders agreement -> MAIN=5.2.dev
5.2 code freeze -> MAIN=5.2.pre1.dev
5.2.pre1 prep -> MAIN=5.2.pre1 --\__ release procedure
5.2.pre1 published -> MAIN=5.2.pre2.dev --/
5.2.fc1 prep -> MAIN=5.2.fc1 --\__ release procedure
5.2.fc1 published -> MAIN=5.2.fc2.dev --/
5.2 prep -> MAIN=5.2 --\
V5-2-patches created -> V52p=5.2.1.dev --->- release procedure
5.2 published -> MAIN=5.3.dev --/
DS> Having introduced the new feature (and split off the V5-2patches
DS> branch) - this is no longer actually the 5.2.x code line.
I know that, historically, the patches branch hasn't been created until after
there have been some fixes and x.y.1 is being built. I'd like to
half-heartedly propose, once again, that it be created immediately following
the pushing of the tarball. I think it goes with the forward looking version
strings.
--
Robert Story; NET-SNMP Junkie <http://www.net-snmp.org/>
<irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>
You are lost in a twisty maze of little standards, all different.
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
