> On 10 Jan 2014, at 12:14 pm, Adam Jensen <[email protected]> wrote: > > > I think I empathize with your general sentiment but I'm not sure I > > understand your proposal. > > > > On Fri, 10 Jan 2014 09:58:05 +1300 > > David Koontz <[email protected]> wrote: > >> > >> The idea of a release is to make a version of the code that > >> doesn't > >> change. It represents a snapshot in development. It implies > >> after a > >> release no one updates the released code. > >> > > > > Yes! I would even extend that and recommend that there be > > *additional* > > snapshots, beyond just releases, that "freeze" significant moments > > of > > development and give them a meaningful label so people can refer to > > these snapshots (and work with them if necessary). > > Record the revision index! Doing so is outside the scope of most > revision systems. The only way to freeze something (prevent someone > one from writing to it) is generate a new revision (check something > in). Once there's a revision it's written in stone (without backing > out changes. > > This is from gna.org, the svn respository viewer. > > I can checkout -r136 and get ghdl0.29. > > With a branch like ghdl-0.31 there's literally nothing stopping a > developer from adding to it, long after 'release'. There is no > branch locking mechanism.
Just to clarify again: this is not the purpose of a branch, but the purpose of a tag. > And notice 'Insert old NEWS file. in both the default branch and > ghdl-0.31 (purple). There is nothing wrong here: a bug can be fixed both in the release branch and in the development branch. > Also notice the revisions are sequence numbers for the repository and > are unique across both branches. > > Branches aside you're dealing with with one repository. > > And contrary to the description revision 244 wasn't the last changes > before 0.31 release. To clarify again: 0.31 hasn't yet been released: no tag, no source packages. [...] > The question arises how you keep someone other than the 'release' > master from writing to the 'release' branch as opposed to the > development branch. If you have one person 'owning' the release > they can back any changes someone else makes out as a matter of > principle. > > It would appear Brian (as the purported release master) let Tristan > walk all over him. My fault here. I should have and I will ask Brian before committing on the release branch. [...] > > A run of the mill developer only needs to remember not to check in to > the default branch during a release cycle. Whose responsibility it > is to resolve the two after an actual release hasn't been defined. > The idea still needs a bit of refinement. > > Don't volunteer to be a release master. No need to main line > caffeine. > > Don't use a release candidate or release except from 'release' > revisions. No mumbling about when you checked out the branch for > testing. > > Naming a branch after a release is dangerous unless you have a way of > preventing writes to that branch after a release. This is what's > being addressed here. Should we simply use branch-0.31 (instead of ghdl-0.31) as branch name to clarify that point ? Tristan. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
