You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Andre Anneck <an...@spmtechnologies.com> on 2003/09/09 08:23:16 UTC
Release Process...
Hi dev-team,
in order to circumvent such conflicts I recommend using CVS branches (early branching):
1. Announce Code-Freeze
2. Open branch RC_0-5
=> Now people can continue work on MAIN, without interference of the release branch
3. Start tagging inside the branch to test release candidates (Maybe Tag-Names == Jira Release-Names)
=> Bugs fixed in release branch need merge into MAIN branch, ok thats the overhead work you have using this approach
4. Once satisfied with stability of RC_05, do the final TAG and produce the release artifacts.
Just my 2EUR's ;),
Take care,
André
_________________________________
Software Development
Andre Anneck
Tel +49 30 55115-305
Fax +49 30 55115-143
andre.anneck@spmtechnologies.com
SPM Technologies Deutschland GmbH
An den Treptowers 1
12435 Berlin, Germany
www.spmtechnologies.com
-----Ursprüngliche Nachricht-----
Von: Jeff Turner [mailto:jefft@apache.org]
Gesendet: Dienstag, 9. September 2003 01:27
An: forrest-dev@xml.apache.org
Betreff: Mixed-namespace support (Re: cvs commit: ...)
On Mon, Sep 08, 2003 at 01:48:15PM -0000, nicolaken@apache.org wrote:
> nicolaken 2003/09/08 06:48:15
>
> Modified: . status.xml
> src/resources/fresh-site/src/documentation/content/xdocs
> site.xml
> src/resources/fresh-site forrest.properties
> src/resources/skins/common/xslt/html document2html.xsl
> Added: src/resources/fresh-site/src/documentation/content/xdocs/samples
> multiple-namespaces.xml html-sample.html
> Log:
> <action dev="NKB" type="add" context="skins">
> In the common skin and derivatives, allow xhtml-namespaced elements in
> document elements to passthrough when rendering to html.
> Added also example in the forrest seed (fresh-site).
> </action>
...
> -#forrest.validate.xdocs.excludes=site.xml
> +forrest.validate.xdocs.excludes=site.xml,samples/multiple-namespaces.xml
Does all this stuff (and @class) *have* to happen a few hours before 0.5
gets released? Couldn't it wait 24 hours for 0.6, when we have a decent
multi-namespace validation system[1] in place?
Same for @class attributes -- I don't care whether it's good or bad; I
don't want to even consider it for 0.5. We can do a 0.5.1 any time.
--Jeff
Re: Release Process...
Posted by Juan Jose Pablos <ch...@che-che.com>.
Andre,
You would have the same issue if just before Code-Freeze someone added a
controversial piece of code, on that case you will have to decide if
you want to revert it or not.
With 4 commiter active this seems to be a bit over head, I like the idea
of code freeze, we only need to have in mind when there is a release and
concentrate on bug fixes rather than on new features.
Say that we want to release around every 8 weeks on the 7th week we ask
ourselves to commit only bug fixes/ minor changes, that would be enough.
Thanks for your 2 Euro cents.
Cheche
Andre Anneck wrote:
> Hi dev-team,
>
> in order to circumvent such conflicts I recommend using CVS branches (early branching):
> 1. Announce Code-Freeze
> 2. Open branch RC_0-5
> => Now people can continue work on MAIN, without interference of the release branch
> 3. Start tagging inside the branch to test release candidates (Maybe Tag-Names == Jira Release-Names)
> => Bugs fixed in release branch need merge into MAIN branch, ok thats the overhead work you have using this approach
> 4. Once satisfied with stability of RC_05, do the final TAG and produce the release artifacts.
>
> Just my 2EUR's ;),
>
> Take care,
>
> André
> _________________________________
> Software Development
>
Re: Release Process...
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andre Anneck wrote:
> Hi dev-team,
>
> in order to circumvent such conflicts I recommend using CVS branches (early branching):
> 1. Announce Code-Freeze
> 2. Open branch RC_0-5
> => Now people can continue work on MAIN, without interference of the release branch
> 3. Start tagging inside the branch to test release candidates (Maybe Tag-Names == Jira Release-Names)
> => Bugs fixed in release branch need merge into MAIN branch, ok thats the overhead work you have using this approach
> 4. Once satisfied with stability of RC_05, do the final TAG and produce the release artifacts.
+1
For now we can simply revert the last changes and release from that, but
next time I propose we follow this process.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------