openjnlp-devel

[Openjnlp-devel] A new version wants to be released

[Kevin H. <ke...@na...>]

OpenJNLP has gone too long without a release. More importantly, there 
are major improvements to OpenJNLP that should have been released 
already (e.g., applet support and the new launcher).

I don't think the current code base is quite ready for a release, but I 
want to do a feature freeze on it. My thinking is that instead of 
stopping work on the main cvs trunk releases should now be branches. 
This will allow work to continue on new features without interrupting 
the release code base. When changes are made on the release branch they 
can be merged back into the main trunk.

This approach is based on my (vast?) cvs experience over the years and 
the good advice from the very good book, "Open Source Development with 
CVS". It happens to be (mostly) free at <http://cvsbook.red-bean.com/>. 
Definately worth a read. The free chapters are the ones that cover the 
mechanics of using CVS.

Re: [Openjnlp-devel] A new version wants to be released

[Christopher H. <he...@ez...>]

On Friday 14 June 2002 11:53 am, Kevin Herrboldt wrote:
[snip]
> My thinking is that instead of
> stopping work on the main cvs trunk releases should now be branches.
> This will allow work to continue on new features without interrupting
> the release code base. When changes are made on the release branch they
> can be merged back into the main trunk.
[snip]

Sounds like a practical plan to me.  I'll follow this next time I'm folding 
in new functionality (for example, Elvis or (possibly) System.err handling).

Do you have any preferred branch naming convention?

					Chris

Re: [Openjnlp-devel] A new version wants to be released

[Kevin H. <ke...@na...>]

On Friday, June 14, 2002, at 04:38 PM, Christopher Heiny wrote:

> On Friday 14 June 2002 11:53 am, Kevin Herrboldt wrote:
[...]
> Sounds like a practical plan to me.  I'll follow this next time I'm 
> folding
> in new functionality (for example, Elvis or (possibly) System.err 
> handling).

Oh no, I think I wasn't clear. When doing new stuff, keep doing it on 
the main trunk. When it's time to feature freeze for a release, the 
frozen code will go on a new branch.

I don't want releases to interfere with adding new features and it 
really reduces headaches for developers if they can keep working on the 
main trunk.

> Do you have any preferred branch naming convention?

I'm planning to document the CVS structure and maybe even include a 
visual aid. My plan now is to stick with the naming convention for 
releases ("ver-0-6" for example). Releases will most likely go like this 
(using "ver-0-7" as an example release):

   bp_ver-0-7      on the trunk as a tag to denote where the branch point 
is
   branch_ver-0-7  branch created from the "bp_ver-0-7" point
   ver-0-7         on the branch as a tag for the release actually 
released
   mp_ver-0-7      on the trunk as a tag to denote where the branch was 
merged back (merge point)

If there's a bug fix for a specific release it will be done on the 
branch for that version and then released as a minor point release. So 
"ver-0-7-1" would be a tag on "branch_ver-0-7" and there would be a 
"mp_ver-0-7-1" merge point on the main trunk to roll the fixes back into 
the main code base.

[Openjnlp-devel] OpenJNLP ver-0-7 branch

[Kevin H. <ke...@na...>]

OpenJNLP has finally branched for the next release. The code on the 
branch will become OpenJNLP 0.7 when it is finally released.

I deviated slightly from my previous message about tag names:

   bp_ver-0-7    is the non-branch tag where the branch was made
   ver-0-7       is the name of the branch

   rel_ver-0-7   will be the name of the 0.7 release, it will be on the 
ver-0-7 branch
   mp_ver-0-7    will be the non-branch tag on the trunk where the branch 
is merged back


What does this mean for development?

For adding new stuff, nothing changes. All bleeding-edge development 
stays on the trunk. If you want to fix bugs for the release, you need to 
switch to the branch with a command like "cvs update -r ver-0-7". Since 
branch tags are sticky, everything you do from that point on will be on 
the "ver-0-7" branch. To get back to the trunk you just do "cvs update 
-A".