On Fri, 25 Jun 2004 15:03:56 +0100 Dave wrote:
DS> I still think we're getting ahead of ourselves.
DS> We need to reach some agreement about what type/frequency/etc
DS> of versioning we want, before it's sensible to think about
DS> the practicalities of implementing it.
DS>
DS> Can I drag people back to Robert's original two questions:
DS>
DS>
DS> >> 1) How to identify the cvs branch.
DS> >> 2) If/How to identify branch version.
DS>
DS>
DS> The first one ought to be fairly straightforward:
DS>
DS> >> a) based on previous release (5.1.1-cvs/5.1.1+cvs)
DS> >> b) based on next release (pre-5.1.2[-cvs])
DS> >> c) based on branch tag (v5-1-patches)
DS>
DS> Of those three, the most useful is probably the first (IMO).
[snip]
DS>
DS> This feels more natural than looking forward to the "next"
DS> release (which might not be for months, if ever).
[snip]
DS>
DS> So whatever approach we use, I'd suggest it's based on
DS> the most recent release string from that line.
DS> Are there any disagreements about that?
Yes, of course. ;-)
Actually, for branches, I agree that (a) is reasonable. However, for main, I
like (b) better. eg, right now I see main as "what will be 5.2", not "what was
5.1 + changes" (that would be v5-1-patches).
DS> Otherwise we can concentrate on the second question - what
DS> (if any) "within-branch-version" identification there should be
DS> (and how frequently it should be updated).
DS> The options seem to be:
DS>
DS> i) No internal versioning
DS> ii) A monthly/weekly/daily "counter" (XXX-N)
DS> iii) A datestamp (XXX-yyyy-mm-dd)
DS> (updated once a day, maximum)
DS> iv) A date-n-time-stamp (XXX-yyyy-mm-dd-hh:mm:ss)
DS> (updated whenever *any* change is made)
DS> ii) PRO: Reasonably simple, adaptable to various
DS> update frequencies (& hence CVS impact)
DS> CON: Not very meaningful string
I think this is the best compromise. Originally I was thinking of an automated
process (weekly seemed reasonable). But, given the validity of your automated
update and 'meaningless string' objections, I'd could live with a manual
update, instead of automated. When a new feature or significant change is made,
bump the number. eg anything significant enough for a Release Note entry would
warrant a bump.
DS> iii) PRO: Much more meaningful than ii),
DS> Clear version comparisons
DS> CON: Lots of (trivial) CVS activity
DS> May need automated updating mechanism
DS> (?SF-cron, ?Makefile rule)
DS> Can't distinguish between v.close changes
I wouldn't mind a timestamp, but I'd say that it should be triggered by
cvs activity, not simply by time. eg start/reset a N hour timer on each
checkin. After the timer expires, update the timestamp. A good value for N
would probably be 4-12 hours.
--
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
