My fault. A lack of communication and synchronisation. I thought we were still in release candidate mode. I committed some changes in the release branch, mostly to doc files, and also to fix a regression. Now that the test suites are clean for me, I don't plan to commit anything else.
Here is how I understood the release process (and I may not have explained correctly). Creating a release branch means creating a branch in the repository, and adjusting version numbers. Once a branch was started, commits are still possible. In particular, any regressions in the release branch could be fixed. Once the release branch is good enough, the release could be created: a source package and binary packages. At this point this is a snapshot. Maybe only the release manager can commit in the release branch, to clarify the process. I will be ok with that policy. So anyone must ask Brian before committing in ghdl-0.31 branch. Below are my answers. > 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. I think you are confusing a branch and a tag. A tag represent a snapshot, and for release branch, it shouldn't change. A branch represent a line of commits. It is possible to fix a bug in the release branch, > Between you and Brian there have been 11 changes since establishing > the ghdl-0.31 branch. That's OK and normal to me. > Don't all the changes invalidate any testing being done by others? Yes for most of them, no for changes in the doc. But we didn't clarify when testing started. > It's called trying to hit a moving target. You've got developers > mumbling about when in time they built from which also sounds like > an argument for release candidates. I agree this was not clear. For me we were still in candidate mode on the release branch, that is testing before the release. And for my part, the testing is OK and I don't plan to commit anything else on the branch. > As far as actually releasing a branch and then not tinkering with it, > it sounds likes it takes developer self discipline, there don't > appear to be any other interesting ways to 'freeze' a branch. I agree with the need of discipline. > Trying to keep separate branches doesn't protect a released version. > The changes we've seen dribble in proves the self discipline > necessary to prevent editing history might be elusive, while > expunging revision check points would require extensive work. > > It seems more likely branching and re-merging would be more > effective. You could tie a release at a particular revision that > way. I think it would involve branching off a development branch > while the main branch goes through release candidate then release > stages, followed by the development branch being merged back in, > fixing the release at a particular revision just as you could fix > release candidates. There is no real distinction between a > development branch, and individual developers branches (whether only > in working copies or not). This is not the usual process. Usually you have 2 parallel lines: one for the release and one for the development. Of course, you create the release branch only when the development branch is stable enough, but you could continue to stabilise the release branch while continuing development in the development branch. > There doesn't appear to be any meaningful parallelism in the release > process until an actual release and it doesn't make good spectator > sport. I personally don't have any problem with it being delayed > until both the release and the process is right. I've given up > doing daily builds until there's something identifiable and > immutable. > > Mind I was shocked to find there have been no tickets opened since > the 'release' began. It says we're all Waiting for Godot. (And I > confess to having never seen the play). The issue being lack of > parallelism for ghdl developers. About tickets: I don't want to be too formal about that. We don't need tickets for development. We don't need tickets to fix minor issues in the release branch. But we need to explain by mail the commits in the release branch. And from now, if nobody is against, we should ask the release manager (Brian) before committing in the release branch. I think tickets are for user reports. > I'd imagine testing against particular release candidates would work > well, having identifiable revision points in the code base. I agree with that. > I used to keep a file containing revision pointers to ghdl releases > in the gna svn code base. > > The distinction between what you have now and what I've described is > minor. Instead of a ghdl-0.31 release branch, release in the default > branch. Create a ghdl-0.32dev branch for ongoing development work. > Once the release is finalized merge the dev branch back in, fixing > the release firmly (and finally) in the revision history. It > doesn't preclude release candidates. I am not against what you propose, for the future. But this is not standard. This looks more like how I worked before mercurial: no branches. For 0.31, you propose something different from what we have (at least to my understanding). > There is no concept of maintenance on a particular ghdl release when > there are no identifiable separate components, and everything is in > the same source tree here. Doing necessary maintenance is the > equivalent of a ghdl-0.29-1 for Windows, and as painful as it would > be should go through release. Incremental fixes from some point in > the revision history sound a lot harder. I don't really agree with that: this is not standard. If you have found a major bug in a release, it is often simple to just fix the release instead of doing a new release. Hence the minor revision number in a release number. > This'd only be a problem when you are forced to merge incompatible > (incomplete) development into a new release. You could patch from a > particular revision history, but should note that the ghdl-0.29-1 > download link on ghdl.free.fr pointed to ghdl-0.29 until I patched > the link about a year ago. In the mean time we had Windows users > swearing ghdl was broken. I think the 0.29-1 issue was mostly a web site issue, but not a release one. > Doing something special requires extraordinary attention to detail. Sure. I hope I clarified a little bit my view of the release process. Thanks, Tristan. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
