Good point. I actually considered introducing this kind of scheme in the VersionInfo field, but got vexed by the
"Keep to 27 chars" comment. Anybody knows about that? Why 27? Would less be critical? More? If we can manage it reasonably, I would like to introduce an Enum just tagging release-type to that string. Other than that, the revision number should be in there. Best regards, Stefan Andersson Tribal Media AB > Date: Wed, 11 Mar 2009 15:11:56 -0400 > From: [email protected] > To: [email protected] > Subject: Re: [Opensim-dev] Proposal: Light-weight Release Cycle > > On 2009-03-11 07:49:46 -0400, [email protected] wrote: > > 7) The "-release" tag is branched to a "-post-fixes" branch for continued > > service awaiting the next cycle. > > May I request that anything committed to -post-fixes after branching > result in an incremented tag (0.6.4.1-release or 0.6.4a-release or > something) & accompanying change in VersionInfo.cs? Otherwise one > has no way of knowing whether someone is running the tagged release > or one of the versions that came out of the -post-fixes branch. There > was a lot of confusion in #opensim with 0.6.3 because changes were > committed to the -post-fixes branch but the versions both before and > after the commit were referred to as "0.6.3". > > Thanks. > > -Coyle > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
