Re: [Jsynthlib-devel] Name for refactored branch

[frankster <jsy...@te...>]

On 09/02/11 02:06, Vladimir Avdonin wrote:
> On 09/01/2011 07:54 PM, Joe Emenaker wrote:
>> Okay, I think I understand Subversion enough to be dangerous.
>>
>> I'll need to make a branch to upload my refactored version to. All of
>> the branches seem to be named after version numbers, but my
>> understanding is that we can name them anything (like "my_cool_branch").
>>
>> Should I name it some step forward in version number (like 0.3,
>> perhaps), or name it something like "refactor"? What does the group
>> think is the best way to go on this? Personally, I'd prefer the version
>> number because, 1) I consider this to be a rather significant step
>> forward in the "sorting out" of the mess of classes that is the main JSL
>> codebase (hence, my desire to call it something like v0.3), and 2) it's
>> more in keeping with the current naming convention in the branch
>> folder... so it'll be easier for people to see where it fits in with the
>> rest of the versions.
>>
> I  like naming branches in more descriptive way, so if someone would
> browse repository he could get general idea right from top view.
>
> Naming towards release is not very descriptive, and the plans for next
> release are not documented anywhere.
>
> I would also suggest somewhat further structuring of branches directory.
> You can create subdirectories there based on the purpose of branches
> inside. I could think of three directories: fixes, features, users.
>
> Fixes would be for involved bug resolutions.
>
> Features for development extensive changes.
>
> Users for developers to fiddle with whatever staff the prefer to work at
> the moment.
>
> In such scheme of things you changes would go into features probably.
>
> Just my 2 cents
>
> Regards,
> Vladimir
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

I agree with Vladimir that without a release plan there's no point 
naming your branch after a release! But when we do decide to do a 
release, normally that's the point at which we will probably be taking a 
copy of the trunk into a branch named after the release. Then typically 
you might let that stabilise for a bit and fix any bugs before making it 
publicly available.

Vladimir's suggestion of creating a "users" subdirectory of branches is 
a good one and that directory can contain branches for any old stuff 
that people are working on, or want to share with others before it gets 
committed into the trunk. Generally it will be tidier if the historic 
release branches are stored in a separate place to any short term 
branches that people might be working on.

But on the subject of release plans, how have releases been decided in 
the past? What triggers them? Who has done them? How is it decided when 
they're ready?

It seems to me that as there are several extra synths supported since 
version 0.20, it would be worth getting some kind of release out 
(perhaps alpha quality / unstable version), so that people can make use 
of the work people have done over the last 6 years! And you never know, 
it might attract a bit more interest in the project as well.

frankie