Re: [Jsynthlib-devel] Name for refactored branch

[Joachim <li...@sd...>]

Hi,

 > I could think of three directories: fixes, features, users.

Normally branches are made for different releases. I don't see
a benefit in these three suggested branches as bug fixes have to
be merged with new features anyway. The users branch is a concept
I didn't get.

trunk is the somehow the main branch. If we would develop a 0.3 release
this would normally happen in the trunk.
If we decide to make bugfixes for 0.20 a bugfix branch should created
from the trunk before the development for 0.3 begins. It could e.g. be
named rel_0_20_patches/.
A new 0.20 release with bugfixes would then be called 0.20.1 and tagged
rel_0_20_1. This tagged release can then be found in the tags folder.

So branches are there to be able to work parallel on two different
releases. Or to experiment. If the experiment is successful it can
then be merged with the trunk. An experimental refactoring branch
could eg be called 'refactoring_for_0_3' so that the purpose is clear.

Remember that you can always jump back to a specific revision so a
refactoring can also directly be done in the main branch aka trunk.

Cheers
Joachim




Am 02.09.2011 14:22, schrieb frankster:
>
> 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
>
> ------------------------------------------------------------------------------
> 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
>