<br><br><div class="gmail_quote">On Thu, Mar 27, 2008 at 7:02 AM, Pete Muir <<a href="mailto:pete.muir@jboss.org">pete.muir@jboss.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c"><br>
On 27 Mar 2008, at 10:59, Pete Muir wrote:<br>
> On 27 Mar 2008, at 10:50, Jay Balunas wrote:<br>
>> We followed a similar process at my last company. We found that<br>
>> freezing anything right before a release was not practical.<br>
><br>
> Yup, I think you are right. Especially for patch releases as we do<br>
> most of the work in the run up to release.<br>
><br>
>> We would release the product with included English docs. Where it<br>
>> differs from your plan is that we did not do a follow up release -<br>
>> unless needed for critical bugs. The docs team worked off the<br>
>> tagged rev so that they were always translating the same version<br>
>> as the release.<br>
><br>
> So, did the translated docs get committed into an RCS at all? This<br>
> is what Shane and I were struggling with - the tag needs to reflect<br>
> what was released, so you need somewhere to place the translation.<br>
> We want to avoid putting in a branch for each release.</div></div></blockquote><div><br>I was not deeply involved with the docs so I am not 100% certain, but I believe that the were "labeled" - similar to "tagged" in clearcase :( post release with the same label as the release. This way future packaging contained the translation. This does not seem like the best approach though.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c"><br>
><br>
>> The dev branch was never actually frozen. When the docs were<br>
>> finished we posted the translated documentation on our website.<br>
>> In the original release we had links and information discussing<br>
>> the translated docs and where they could be found.<br>
><br>
> This is other option. It has the downsides that you never get a zip<br>
> with the translated docs so some won't realise they exist and the<br>
> above RCS problem. On the upside it is easier.<br>
><br>
> Another option we discussed would be get just the doc/ dir tagged<br>
> with with the translations post release (e.g.<br>
> JBoss_Seam_2_0_2_GA_TR1) and release a separate zip including<br>
> translated docs.</div></div></blockquote><div> </div><div>I like this tagging approach - because moving forward there are also going to be multiple translations and they probably will not all be finished at the same time. As new ones are completed they can be released.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c"><br>
</div></div>This zip would *just* contain the docs, not the src/, not the built<br>
jars, not the examples and be called e.g. jboss-seam-2.0.2.GA-<br>
documentation.zip</blockquote><div><br>This is how a lot of packages do it (like the sun JDK) they have a document zip/release .<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div><div></div><div class="Wj3C7c"><br>
> This would reduce the QA/release load no end, solve the RCS problem<br>
> and possibly be good as it means those who just want code don't get<br>
> bloat from all sorts of extra docs. This could also be good as it<br>
> would allow the docs team to work mostly independently after a<br>
> release and provide translations as fast as they need (just tag<br>
> each rev TRx, upload to <a href="http://sf.net" target="_blank">sf.net</a>, update <a href="http://docs.jboss.org" target="_blank">docs.jboss.org</a> and update<br>
> <a href="http://seamframework.org" target="_blank">seamframework.org</a>).<br>
><br>
> WDYT?</div></div></blockquote><div><br>I think it sounds good as long as these releases are only the docs. They would be a zip that you could extract into the release and it would just lay down the update.<br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c"><br>
><br>
><br>
>><br>
>><br>
>> Both approaches have there benefits, but I would suggest we do<br>
>> something like this because I think that it will free more time<br>
>> for other tasks.<br>
>><br>
>> Obviously I could go either way though.<br>
>><br>
>> Jay<br>
>><br>
>> On Thu, Mar 27, 2008 at 5:39 AM, Pete Muir<br>
>> <<a href="mailto:pmuir@bleepbleep.org.uk">pmuir@bleepbleep.org.uk</a>> wrote:<br>
>> Samson,<br>
>><br>
>> You've previously raised the issue of how we allow the JBoss Content<br>
>> Team to work on translation/documentation and requested that we<br>
>> freeze<br>
>> the documentation approximately 2 weeks before we release.<br>
>><br>
>> Having thought about this some, we don't think that this is really<br>
>> practical. So here is our alternative proposal:<br>
>><br>
>> 1) We release Seam <a href="http://X.Y.Z.GA" target="_blank">X.Y.Z.GA</a> with the English docs as prepared by Seam<br>
>> committers. This allows users quick access to the code and also to<br>
>> updated docs<br>
>><br>
>> 2) We freeze this branch for around 2 - 3 weeks except for any<br>
>> critical code fixes and documentation/translation work<br>
>><br>
>> 3) We then release Seam X.Y.Z.SP1 with any critical fixes and<br>
>> translations<br>
>><br>
>> Jay,<br>
>><br>
>> This obviously increases the QA/release managers load so I propose<br>
>> that only extremely critical fixes make it into the code, examples or<br>
>> seam-gen. As the release testing and process is increasingly<br>
>> automated<br>
>> this should become easier. What do you think?<br>
>><br>
>> Pete<br>
>><br>
>> --<br>
>> Pete Muir<br>
>> <a href="http://in.relation.to/Bloggers/Pete" target="_blank">http://in.relation.to/Bloggers/Pete</a><br>
>> <a href="http://www.seamframework.org" target="_blank">http://www.seamframework.org</a><br>
>> _______________________________________________<br>
>> seam-dev mailing list<br>
>> <a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> seam-dev mailing list<br>
> <a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
<br>
</div></div><font color="#888888">--<br>
Pete Muir<br>
<a href="http://www.seamframework.org" target="_blank">http://www.seamframework.org</a><br>
</font><div><div></div><div class="Wj3C7c"><a href="http://in.relation.to/Bloggers/Pete" target="_blank">http://in.relation.to/Bloggers/Pete</a><br>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br>