> 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).
I would prefer to release often than creating additional snapshots. The first release is always a heavier process because the process has to be established. I hope next releases would be lighter. > > 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. Sure. > > 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). Changeset ids and tags are for that: identifying a state of the sources. Branches aren't for that, because they are lines. > > 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. I agree. Re-labeling shouldn't be allowed. > > 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. For FreeBSD, I'd like to see this issue fixed, but I don't really know how to help. > > 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. Tristan. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
