Peter Clifton wrote: > On Fri, 2010-02-19 at 19:05 -0500, Dan McMahill wrote: >> Peter Clifton wrote: >>> On Fri, 2010-02-19 at 09:53 -0500, Julian wrote: >>>> Hello all, >>>> The list has been fairly quit, so I thought I'd see if anyone was >>>> game to push out a new release. I haven't added any new features, but >>>> we've had a steady stream of bug fixes in the past 8 months or so, so >>>> it would be nice to get them out to everyone. I can potentially roll >>>> up a release too, but have never done it before so it might be less >>>> trouble for someone else. Let me know your thoughts-- >>>> >>>> Julian >>> If there have been no new "features", then release 2.3.1, and we can >>> look at getting a freeze-exception for including it in Ubuntu Lucid. >>> Ubuntu Lucid will be a long-term-supported release, so is likely to see >>> more users (over a longer time period) when compared to a normal Ubuntu >>> release. >>> >>> Best wishes, >>> >>> Peter C. >> I would need help in figuring out how to pull up all the changes then to >> the gerbv-2-3 branch. I don't want to release 2.3.1 starting from >> somewhere besides the 2-3 branch.
> This commit might not be considered a bug fix by some upstreams if they > looked closely though: > This is not a bug fix. thats kind of what I was thinking too. tbh it feels a little silly to try and force ourselves into a teeny version bump just to satisfy getting into some particular distribution of something or other. I've always felt like if we had the teeny version ever at something than 0 it was because we messed up. I have a different viewpoint for something large like an entire operating system where there is a whole lot more activity and I think more benefit to longer term stable releases that have bug fixes coming out. For a small project it feels like a lot of effort for questionable benefit. > > >>From my checkout, it seems that you don't actually have a stable branch > - just some tags (CVS legacy?) You could create the stable-2.3 branch > from git HEAD, then do your release engineering on it, or you could > "pretend", go back and create a branch from the gerbv-2-3-RELEASE tag. > the branch would probably come from the gerbv-2-3-base branch point tag then. We've not done a release yet with git, but I'm certain there were branches in cvs. I hope that didn't get lost in the transition. > A further thought - is that you could be evil - and re-write some > history here.. if we pretend that all which is git HEAD "master" is > actually the stable-2.3 branch (Just create a branch of master, then > push), > > then force-update master to match the start of that supposed branch - > e.g. gerbv-2-3-MASTER, you could then merge the stable-2.3 branch (which > was up until just now "master"), into the new "master" branch - as if > they were all stable updates made on the stable branch. > > Slightly naughty in terms of people who might be working on top of the > master branch, but it ought not to be insurmountable. > > Thoughts? sounds like a lot of jumping through hoops just to get a version number that someone in another project (whatever distro that was) likes! -Dan ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Gerbv-devel mailing list Gerbv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gerbv-devel
