On Fri, 2014-01-10 at 09:58 +1300, David Koontz 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. > > Between you and Brian there have been 11 changes since establishing the > ghdl-0.31 branch.
At this point I have to step forward, repeat my apology, and explain more. This started when I tentatively tagged a commit as ghdl_0.31rc1, and Tristan suggested we needed a ghdl-0.31 branch. His suggestion was, as usual, spot on, but I (not for the first time) fumbled the pass, thinking he meant 0.31 was ready for release. Actually the branch is there to enable the last details of 0.31 to stabilise without stopping forward development on "default". Calling it the release was entirely my misunderstanding! (More backstory later...) You cannot freeze a branch. What you can do is freeze a release point within that branch by tagging it; expect to see a "ghdl-0.31_release" tag (or other wording if anyone can improve on it) in the next day or so. Even then, further commits in the branch are possible : e.g. to fix major security holes. After sufficient of these, we may tag a further release point "ghdl-0.31_security_update_1" or "ghdl-0.31.1_release" or whatever. I don't believe we will; it's not as if we are building a kernel here. SO... I created the ghdl-0.31 branch. 1) I should have tagged its first commit as ghdl-0.31_rc1 and apologise for failing to do so. 2) When Tristan says (in response to this message) he is finally done, I will tag the current head as "ghdl-0.31.1_release" and the actual release will be fixed. This constitutes my permission for one more commit if there is anything to commit, and a request for Tristan to reply. 3) In future, the ghdl-<version> branch AND a RC1 tag will be established shortly before release, to allow the release to settle before it is tagged and fixed. 4) We have changed a LOT of things at once with this release. Repository, VCS, moving from a solo project to a new small team, establishing (in my case by misunderstanding then learning) the process on the fly. If this is the worst that happens, then I think we're OK (but see backstory)... 5) The commit history on the 0.31 branch gives us a checklist where version dependencies, dates, etc are lurking and need changing with each release. In addition to documenting the process, this checklist will save time next time (a "check_versions" script, or target in dist.sh may automate this part of the release.) I'm sure Tristan had a good mental model of what needed to happen; transitioning to team means this model has to become explicit. > Don't all the changes invalidate any testing being done by others? > It's called trying to hit a moving target. To an extent yes; though documentation fixes are unlikely to invalidate a test run. In future, there will be 2 versions for testers to worry about : the RC1 (at the root of the branch) and the final release version : we probably need to freeze it as RC2, wait for success reports, then re-tag it as Release. And the backstory : I actually did tag what I thought was ready for release as "ghdl-0.31". That would have been a fixed point whatever else happened in the branch. Unfortunately something is broken in SourceForge. If a tag and a branch have the same name, the tag hides the branch in the SF repo browser, and the branch effectively disappears altogether! (Naturally all appeared OK in your own repo, browsed using hg, before pushing that commit!) When you do this late at night after your wife has gone to bed and you promised to create the release branch tonight, you might panic a bit... In the end, removing the offending tag and pushing that, restores the repo to sanity. In the rush of relief, do you remember to re-tag that release as RC1 and push it, or (believing it is really ready for release) do you go to sleep? I think I chose wrong... - Brian _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
