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. Don't all the changes invalidate any testing being done by others? 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. 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. 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). 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. I'd imagine testing against particular release candidates would work well, having identifiable revision points in the code base. 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. 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. 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. Doing something special requires extraordinary attention to detail. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
