[...] > 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.
For the next release, I propose to name the branch 'branch-0.32' and releases 'ghdl-0.32', 'ghdl-0.32.1' ... > 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. Yes, I am finally done. I have tested ghdl_mcode with the different testsuites. > 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)... Yes, we are learning and establishing new processes. > 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. Previously, I never made branches, so the new process is really new. > > 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. That's fine with me. > 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... No problem. The first release is never an easy one! Tristan. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
