[jbosstools-dev] Re: We have branched - Codefreeze and status

[Sean Flanigan]

Max Rydahl Andersen wrote:
>> So, if I understand correctly, trunk is still frozen for new work?  Will
>> the GA release will eventually happen from trunk, rather than the CR
>> branch?  Does that mean that the CR branch is not really a Candidate for
>> [GA] Release?
>>    
> Right now the CR branch is for stabilizing for the release this week.
>> Why not call the branch the 3.0 branch, to be used for
>> stabilisation/bugfixes now, and eventually to become the 3.0 maintenance
>> branch?
>>    
> We will be creating such a branch when we get near GA release. 
> Unfortunately we got a good bunch
> of issues left for GA yet which we are currently just using trunk for to 
> avoid the overhead of
> double branch maintenance for the whole team.

Couldn't you just use the "CR" branch for that? (By another name,
preferably.)  I don't really understand what changes would go into trunk
but not into the branch.  If the answer is "no changes", then the branch
is redundant at present, is it not?  Or are you saying there are issues
which we intend to fix (in trunk) for GA, but not for the the CR?

>> I guess I'm having trouble understanding the conventions of
>> trunk/branches in this project.  Perhaps there is a wiki page to cover
>> this sort of thing?
>>    
> I should probably create such :)
>> Do I need to hold off on string externalisation (JBIDE-3557) until after
>> GA?  I don't plan to break the trunk build (who does?), but even small
>> changes need QA before release.   (If you're just saying not to make
>> architecture-breaking changes in trunk, then that's different.)
>>    
> Safe string externalisation I'm ok with, I assume you did you *big* 
> change a few weeks back, correct ?

So far, excluding the "i18n" folder, everything I've done has been
simple string externalisation, nothing *big*.  Just lots of small
changes.  Looking at the changesets, I haven't checked in any .java changes.

Even so, it may not be 100% safe, since I had to do most of it by hand
(no wizards for some things).  As much as possible, I have tried to
smoke-test them in the GUI, but it's difficult to test every string when
you don't know the GUI inside out.

Most of the remaining externalisation will be the easier, wizard-driven
type, except where I have to introduce MessageFormat.  However, once I
start externalising entire plugins, rather than targeting individual
strings from the GUI, comprehensive testing will become much more
labour-intensive.

> And yes, I'm saying don't make big functional changes or additions in 
> trunk - make bugfixes.

Is 18n a feature, or are unexternalised strings bugs? :-)

-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20090127/4032b835/attachment.bin