> Dave's examples did not include one for the HEAD CVS branch.
No - because I was just trying to illustrate the basic idea
in the couple of minutes before I had to dash to get the train.
I wasn't expecting this to be taken as a formal, polished proposal!
> Niels, Did you just write that you build the date and branch
> into one of the sources, at build time ?
>
> Personally, I think that would be best to use, since it
> represents the least work for the -coders %^)
Errr.... I do hope not.
That would potentially mean that the version file would be
updated every time anyone compiled the source - whether or
not any other files had actually been changed!
Remember that there's a difference between what happens in
a local developer's working code, and what happens with the
central repository. If *every* compilation updates the
version file, then the CVS logs are going to get ridiculous!
I still think we're getting ahead of ourselves.
We need to reach some agreement about what type/frequency/etc
of versioning we want, before it's sensible to think about
the practicalities of implementing it.
Can I drag people back to Robert's original two questions:
>> 1) How to identify the cvs branch.
>> 2) If/How to identify branch version.
The first one ought to be fairly straightforward:
>> a) based on previous release (5.1.1-cvs/5.1.1+cvs)
>> b) based on next release (pre-5.1.2[-cvs])
>> c) based on branch tag (v5-1-patches)
Of those three, the most useful is probably the first (IMO).
It effectively treats each release (including pre-releases
and release candidates) as a "named checkpoint",
and indicates that the code is a development from that.
This feels more natural than looking forward to the "next"
release (which might not be for months, if ever).
And the branch tag isn't really informative enough, IMO
(even with date/time information added). One of the
most vital things IMO is to be able to relate CVS code
to the released versions.
So whatever approach we use, I'd suggest it's based on
the most recent release string from that line.
Are there any disagreements about that?
Otherwise we can concentrate on the second question - what
(if any) "within-branch-version" identification there should be
(and how frequently it should be updated).
The options seem to be:
i) No internal versioning
ii) A monthly/weekly/daily "counter" (XXX-N)
iii) A datestamp (XXX-yyyy-mm-dd)
(updated once a day, maximum)
iv) A date-n-time-stamp (XXX-yyyy-mm-dd-hh:mm:ss)
(updated whenever *any* change is made)
The {dis,}advantages of each of these (as I see them) are
as follows:
i) PRO: Simple, clear, easy to achieve manually,
minimal impact on CVS traffic
CON: Can't distinguish between two versions of development tree.
ii) PRO: Reasonably simple, adaptable to various
update frequencies (& hence CVS impact)
CON: Not very meaningful string
iii) PRO: Much more meaningful than ii),
Clear version comparisons
CON: Lots of (trivial) CVS activity
May need automated updating mechanism
(?SF-cron, ?Makefile rule)
Can't distinguish between v.close changes
iv) PRO: V. fine versioning, distinguish between all changes.
Equally meaningful as iii)
CON: Large amount of CVS activity
Probability of CVS clashes.
Delay between build and commit
(assuming Makefile-based update)
Does anyone want to add any others, expand on any of these, or
query what on earth I'm babbling on about?
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
