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
Dave> It would still leave the option of a format such as
Dave> 5.1.2.cvs.2004/08/01
Dave> or 5.1.2.cvs-2004/08/01
Robert> I'd like to recommend that we avoid path separators:
Robert> eg '/', '\' and ':'.
That rather proves the point I made immediately afterwards:
Dave> I suspect we're not going to come to a quick consensus
Dave> here. For now, how about we just adopt the bit that we *are*
Dave> in agreement over (marking with ".cvs") and see how it goes.
DS> It looks as if the general preference is to distinguish "preN" and
DS> "preN+CVS" code - correct?
Robert> Sort of. I'd like to suggest that the version string for a release
Robert> (x.y, x.y.preN, etc) only exist for a brief moment in time, during
Robert> the creation of a release. As soon as a tarball is published, cvs
Robert> is updated to indicate that it is now development code.
<nods>
Yes - that's pretty much what I was assuming.
So the release process would be:
- update the version tag(s) to indicate the "non-CVS"
nature of the release
- do whatever other fiddling is needed
- create the tarball
- update the version tag(s) to indicate that things are CVS
again (based on the new release number)
Robert> While that does mean that, until a fix is checked in, there are two
Robert> different version strings (x.y, x.y.1) for exactly the same code.
Robert> I don't see a problem
Nope - neither do I.
One is referring to a fixed code snapshot - the other is work-in-progress.
(The fact that we'll have made no actual progress may be disappointing
but not entirely unexpected :-) )
Robert> Here's an example of what I'd like to see for the 5.2. release line:
[snip]
I'm in full agreement with *most* of that - certainly everything up to the
full 5.2 release point.
Dave> Having introduced the new feature (and split off the V5-2patches
Dave> branch) - this is no longer actually the 5.2.x code line.
Robert> I know that, historically, the patches branch hasn't been created
Robert> until after there have been some fixes and x.y.1 is being built.
Sort of - the trigger for x-y-patches is not the application of fixes
and/or the desire to release x.y.1. The trigger has been a new feature
that was deemed *not* appropriate for an x.y.z release.
For example, the 5-0-patches line didn't break off from the main
development line until after v5.0.7 was released. That means there
were seven minor releases (over a period of approx. 8 months) during
which we didn't feel the need for separate bug-fix/development lines.
Robert> I'd like to half-heartedly propose, once again, that it be created
Robert> immediately following the pushing of the tarball.
I'd like to whole-heartedly reject that proposal. It's just going to
cause additional (unnecessary) work. Do you want me to count how
many changes were applied between the 5.0 release and the V5-0-patches
branch being created? If we'd created the patches branch immediately,
every one of those would have had to be done twice.
Sure - if we know that there are some significant additions that are
waiting to be applied, then it makes sense to split off a patches
branch fairly quickly. And I somehow doubt that we'll go eight
months before adding such a "new feature" in the future. But I
don't see the point in splitting the CVS tree prematurely.
In fact, I'd like to put forward a counter proposal that we have a
deliberate policy to *not* split off the patches branch (or apply
any significant new features) for two weeks after an x.y release.
That gives us time to discover any significant problems that didn't
come to light during the pre-release testing.
After all, an x.y release marks a significant change in the latest
"stable" code base, as used by Joe Public. So the immediate priority
has got to be consolidating this, and making sure it's suitable for
general use. We're not going to be making another x.y-level release
for quite a while (say 4 months, minimum!) so there's no rush to get
new features into the CVS tree. While it's quite likely that there
will be an x.y.1 release fairly soon after the first (5.0->5.0.1
was ~3 weeks). And the longer we leave it before doing this, the
more it's likely to come back to haunt us in the form of support
queries.
If it becomes clear that this isn't going to be necessary, and there
are new features waiting to be applied, then we can split off the
patches branch. But in the immediate aftermath of a major release,
then I don't think we *should* be looking forward particularly.
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
