Most of the bug fixes were all edge cases, so the user would probably
never notice. However there was a biggy...segfault when clicking
"modify layer orientation" with no open layer.
I would vote for 1) release 2.4 since it's easier, and 2) push to get
2.4 into Lucid by calling it a bug fix (which it is). If they complain
about that one patch for the aperture report, we can send them a diff to
remove that change for their package. It's probably about 10 lines of
code really.
Cheers--
On Sat, 2010-02-20 at 11:50 +0000, Peter Clifton wrote:
> On Sat, 2010-02-20 at 01:48 -0500, Dan McMahill wrote:
>
> [snip]
>
> > 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.
>
> Call it 2.4 then.. its not as if the number makes a difference to the
> feature freeze exception process.. you still have to provide a diff, and
> justification for it. I would think that upstream using micro-releases
> for bug fixes probably helps clarify that the upstream has a stable
> release update policy though - and they are perhaps less likely to be
> suspicious of a micro release.
>
> > 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.
>
> My feeling is different there. I think the minor/micro bump system in
> gEDA has been working well. It allows us to provide a stable platform
> without unduly constraining git HEAD development after a release "just
> in case", and proved very useful in the 1.4.x series (and looks like it
> will for 1.6.x). It might not be right for every project though.
>
> [snip git hackery]
>
> > sounds like a lot of jumping through hoops just to get a version number
> > that someone in another project (whatever distro that was) likes!
>
> Perhaps - it just depends what the gerbv developers want really - and
> I'm too far detached from it now to feel any right to input there.
>
> Branches in git won't show where they came from until they deviate... so
> you could just as well fork off a stable-2.3 branch from git HEAD, then
> release from there.
>
> Best wishes,
>
> Peter c.
>
>
>
> ------------------------------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gerbv-devel
Julian
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/gerbv-devel
