[seam-dev] Updates to Seam release process to allow for translation work

[Pete Muir]

On 27 Mar 2008, at 10:59, Pete Muir wrote:
> On 27 Mar 2008, at 10:50, Jay Balunas wrote:
>> We followed a similar process at my last company.  We found that  
>> freezing anything right before a release was not practical.
>
> Yup, I think you are right. Especially for patch releases as we do  
> most of the work in the run up to release.
>
>> We would release the product with included English docs.  Where it  
>> differs from your plan is that we did not do a follow up release -  
>> unless needed for critical bugs.  The docs team worked off the  
>> tagged rev so that they were always translating the same version  
>> as the release.
>
> So, did the translated docs get committed into an RCS at all? This  
> is what Shane and I were struggling with - the tag needs to reflect  
> what was released, so you need somewhere to place the translation.  
> We want to avoid putting in a branch for each release.
>
>> The dev branch was never actually frozen.  When the docs were  
>> finished we posted the translated documentation on our website.   
>> In the original release we had links and information discussing  
>> the translated docs and where they could be found.
>
> This is other option. It has the downsides that you never get a zip  
> with the translated docs so some won't realise they exist and the  
> above RCS problem. On the upside it is easier.
>
> Another option we discussed would be get just the doc/ dir tagged  
> with with the translations post release (e.g.  
> JBoss_Seam_2_0_2_GA_TR1) and release a separate zip including  
> translated docs.

This zip would *just* contain the docs, not the src/, not the built  
jars, not the examples and be called e.g. jboss-seam-2.0.2.GA- 
documentation.zip

> This would reduce the QA/release load no end, solve the RCS problem  
> and possibly be good as it means those who just want code don't get  
> bloat from all sorts of extra docs. This could also be good as it  
> would allow the docs team to work mostly independently after a  
> release and provide translations as fast as they need (just tag  
> each rev TRx, upload to sf.net, update docs.jboss.org and update  
> seamframework.org).
>
> WDYT?
>
>
>>
>>
>> Both approaches have there benefits, but I would suggest we do  
>> something like this because I think that it will free more time  
>> for other tasks.
>>
>> Obviously I could go either way though.
>>
>> Jay
>>
>> On Thu, Mar 27, 2008 at 5:39 AM, Pete Muir  
>> <pmuir at bleepbleep.org.uk> wrote:
>> Samson,
>>
>> You've previously raised the issue of how we allow the JBoss Content
>> Team to work on translation/documentation and requested that we  
>> freeze
>> the documentation approximately 2 weeks before we release.
>>
>> Having thought about this some, we don't think that this is really
>> practical. So here is our alternative proposal:
>>
>> 1) We release Seam X.Y.Z.GA with the English docs as prepared by Seam
>> committers. This allows users quick access to the code and also to
>> updated docs
>>
>> 2) We freeze this branch for around 2 - 3 weeks except for any
>> critical code fixes and documentation/translation work
>>
>> 3) We then release Seam X.Y.Z.SP1 with any critical fixes and  
>> translations
>>
>> Jay,
>>
>> This obviously increases the QA/release managers load so I propose
>> that only extremely critical fixes make it into the code, examples or
>> seam-gen. As the release testing and process is increasingly  
>> automated
>> this should become easier. What do you think?
>>
>> Pete
>>
>> --
>> Pete Muir
>> http://in.relation.to/Bloggers/Pete
>> http://www.seamframework.org
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev

--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete