Dave> R 5.1.1
Dave> C 5.1.1+cvs 2004/06/01
Dave> R 5.1.2.pre1
Dave> C 5.1.2.pre1 2004/07/01
Wes> I don't think the reported version number as released by the tools
Wes> should have anything other than things parsable by .s. IE, 5.1.1.cvs
Wes> and 5.1.2.pre1.cvs should be the only style things we use.
Sure - that makes sense.
It would still leave the option of a format such as
5.1.2.cvs.2004/08/01
or 5.1.2.cvs-2004/08/01
of course, but I suspect we're not going to come to a quick consensus
here. For now, how about we just adopt the bit that we *are* in
agreement over (marking with ".cvs") and see how it goes.
We can always add a datestamp or serial number later, if we decide
that would be worthwhile.
It looks as if the general preference is to distinguish "preN" and
"preN+CVS" code - correct? That makes a slightly longer version
tag than I'd ideally like, but it shouldn't be hanging around for
long, so I can live with that.
OK - so that just leaves the question of what nomenclature to use
for the main development branch.
Robert> I think we probably shouldn't use pre0, since we use preN
Robert> for release tags.
Yup.
And we have indeed used "pre0" for making a "long-term pre-release".
In rather unusual circumstances, I'll grant you - but it's not
impossible that it might happen again.
And sorry, Robert, but I agree with Wes - "sera" is cute, but we
need something a little more obviously meaningful.
Wes> My preference would be to take the current version just
Wes> released and auto-append a .cvs to the end.
Yup - that's my preference too.
So let's follow through what happens following a (major) release
using this approach:
"5.2" (released version)
[ assorted minor bug-fixes ]
(a) "5.2.cvs"
[ significant new feature ]
At which point we'd open a new V5-2-patches branch, giving:
(b) "5.2.cvs" (main development version)
+
(c) "5.2.cvs" (v5-2-patches version)
[further bug-fixes, leading to]
"5.2.1" (released bug-fix version)
"5.2.1.cvs" (and away we go again)
The problem is how to distinguish between the three "5.2.cvs" tags,
and in particular, between (b) and (c) - Yes?
Now from a CVS point of view, (b) follows immediately on from (a),
and (c) breaks off into a separate branch (e.g. CVS version numbering).
But it strikes me that in terms of the actual code, it's (c) that
follows seamlessly on from (a), and it's (b) that involves the jump.
So I'd be inclined to leave (a) and (c) both marked as "5.2.cvs"
and introduce a new version tag for the main development line.
Something like "5.2.development" or "5.2.main" or similar.
And although I've been arguing in terms of looking back rather
than looking forward, I think I'm about to change my mind.
Having introduced the new feature (and split off the V5-2patches
branch) - this is no longer actually the 5.2.x code line.
It's now the code that will (eventually) become 5.3 (or possibly 6.0).
So it wouldn't be unreasonable to mark it as "5.3.development"
or something similar. (With the "development" tag changing to
"preN" when the pre-release code chill starts).
That way the "base version" of the tag reflects the broad status
of the code. The change of tag following the emergence of the
-patches branch also serves as an indication that there's now
another branch to be considered when applying patches.
How does that sound as a basic model?
And if it's acceptable, what should we use as the main branch tag?
Is "5.3.development" OK, or are there any better suggestions?
("development" is preferable to "main" IMO, since it makes the
incomplete nature of the code somewhat clearer).
Dave
-------------------------------------------------------
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
