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). > Between you and Brian there have been 11 changes since establishing > the ghdl-0.31 branch. > The engineering processes and procedures are a bit ad-hoc at the moment. I agree, it's not a very effective way to do things for a long-term group project. > 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. > Yep. Furthermore, how do you refer to the version/collection of source you are currently working with? Given the current methods, there isn't a straight-forward and comprehensible way for common-folk to do that (I suppose one could refer to changeset ID's). > 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. > Re-labeling is a problem. > 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 where I have a little trouble following the idea. Maybe I'm a little dull at the moment. I'll fetch a cup of coffee and try to draw a diagram, but for now, I don't really get it. > 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. > Yeah, I've stopped daily builds *and* there is at least one test that fails unexpectedly on FreeBSD. > 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. > LMAO@Godot. Definitely. > I'd imagine testing against particular release candidates would work > well, having identifiable revision points in the code base. > Yes, agreed. Release Candidate tags would be very convenient. Then I could submit a ticket - 0.31-RC1 fails vests test: 375 on FreeBSD - then, hopefully - 0.31-RC2 passes all tests on FreeBSD. > 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. > Hmm, I'll have to include this paragraph in my coffee-amplified, idea diagramming session. > 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. > I'm completely lost now. Off to the coffee-kiosk.
signature.asc
Description: PGP signature
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
