End of Hard Freeze for 0.41 Release
Hi all,
Bulia and Kees have given word that the codebase is now ready for release. Ted has tagged and branched, and has posted the release tarball. Kees is working on producing the release packages. We're putting in the final tweaks to the release announcements and notes.
At this time, the codebase is now officially unfrozen and open for regular development.
We have had a very good, strict release with 0.41. We have been very cautious about adding new dependencies, and focused heavily on bug fixing.
For 0.42, we're going to change gears. This release will be much more freeform and open to aggressive new changes. Bug fixing will take second seat to feature implementation and major architectural changes. As soon as you're ready, feel free to merge in code that's been sitting on the sidelines for 0.41.
I expect this will destabilize the codebase for quite some time to come, but that's okay. It may be a number of months before we're ready to make another release, but with such a strong 0.41 release out the door we're well set for this development phase.
During this next phase, there are two rules I think would be worthwhile for us to abide. The first is to strive to always keep the codebase buildable within a day. In other words, be respectful of the needs of other developers by trying to only check in compilable code, and if you don't, to correct it within 24 hrs. Second, if you want to add a new dependency to the codebase, please discuss this on the mailing list first. We definitely can add new dependencies for 0.42 but let's make sure we have a rough concensus favoring it before committing. The first rule will save us pain in the short term, the second will save us pain in the long term. :-)
Thanks everyone, and great work with 0.41! Have fun with 0.42. :-) Bryce
On Tue, 8 Feb 2005 22:37:57 -0800, Bryce Harrington <bryce@...260...> wrote:
During this next phase, there are two rules I think would be worthwhile for us to abide. The first is to strive to always keep the codebase buildable within a day.
Second, if you want to add a new dependency to the codebase, please discuss this on the mailing list first.
Third, strive to fix ASAP any bugs or regressions found in the code you checked in. If you know the code you're about to check in has some unfixable (in the short term, or even at all) regressions, please warn people on the list and try to find a consensus.
I want to stress the need for the CVS to remain usable at all times. Regular users can just stick to 0.41, but developers-users such as myself will want to contribute to the CVS _and_ use it in the daily design work, as was possible up to now, and I don't want to lose this possibility.
Quoting bulia byak <buliabyak@...400...>:
Third, strive to fix ASAP any bugs or regressions found in the code you checked in. If you know the code you're about to check in has some unfixable (in the short term, or even at all) regressions, please warn people on the list and try to find a consensus.
I want to stress the need for the CVS to remain usable at all times. Regular users can just stick to 0.41, but developers-users such as myself will want to contribute to the CVS _and_ use it in the daily design work, as was possible up to now, and I don't want to lose this possibility.
Would it be incredibly gauche of me to add an emphatic "Me too!"? ^_-
-mental
Quoting bulia byak <buliabyak@...400...>:
Third, strive to fix ASAP any bugs or regressions found in the code you checked in. If you know the code you're about to check in has some unfixable (in the short term, or even at all) regressions, please warn people on the list and try to find a consensus.
One thing in particular that I'd like to underscore for the benefit of the list: breakage is, fundamentally, a debt.
The longer code remains broken or disabled, the more difficult it becomes to fix or re-integrate later. This difficulty increases super-linearly with time.
In other words, he longer you remain in debt, the more interest you have to pay.
This is why small, incremental changes are best. It's also why I'm so aggressive about ripping out unused or commented-out code.
-mental
mental@...3... wrote:
Quoting bulia byak <buliabyak@...400...>:
Third, strive to fix ASAP any bugs or regressions found in the code you checked in. If you know the code you're about to check in has some unfixable (in the short term, or even at all) regressions, please warn people on the list and try to find a consensus.
One thing in particular that I'd like to underscore for the benefit of the list: breakage is, fundamentally, a debt.
The longer code remains broken or disabled, the more difficult it becomes to fix or re-integrate later. This difficulty increases super-linearly with time.
In other words, he longer you remain in debt, the more interest you have to pay.
This is why small, incremental changes are best. It's also why I'm so aggressive about ripping out unused or commented-out code.
Maybe then to change Bryce's rule: don't check in broken code. Code for the core application must compile. I think the 24 hour rule should be stricken. This is not to say that merging the gtkmm code into HEAD will not be problematic. As, maybe that code might break the inkscape_gtkmm code, but it should not break the core Inkscape application.
SIMPLY: Inkscape CVS should also be compilable.
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id%14396&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (4)
-
unknown＠example.com -
Bryce Harrington -
bulia byak -
Jon Phillips