Hi

Any other ideas? I'd propose the layout used in servicemix-bundles like 
described some emails ago - a separate maven module/project for each minor 
version of the feature.

Kindly regards
Krzysztof

On 09.02.2017 01:08, Krzysztof Sobkowiak wrote:
> I think it's easier to maintain the content when we have all in one branch. 
> Tag is only a tag on a specific state, it's not a copy of the content.
> With many branches  we quickly lose the ability to easily maintain and 
> oversee the content.
>
> There is also no problem to maintain the feature specific bundles as we can 
> use following structure in this case
>
> feature-2.3.x/bundle1
> feature-2.3.x/bundle2
> feature-2.3.x/bundle3
> ...
> feature-2.3.x/bundlen
> feature-2.3.x/feature 
>
> Kindly regards
> Krzysztof
>
>
> On 08.02.2017 23:58, Jean-Baptiste Onofré wrote:
>> I'm not a big fan of branches that way because it's not easily visible.
>> Git modules is not really an alternative as it would force us to use a 
>> special structure.
>>
>> I don't think it's a problem to tag unused files.
>>
>> Regards
>> JB
>>
>> On Feb 8, 2017, 18:48, at 18:48, Christian Schneider 
>> <[email protected]> wrote:
>>> The naming scheme you propose would match nicely with the current
>>> scheme 
>>> we have in bundles.
>>> What I see as a problem in both cases is that a git tag always covers 
>>> all content. So it would hold a lot of arbitrary files that are not
>>> part 
>>> of the release.
>>>
>>> I have an unusual idea how we might do better.
>>>
>>> How about using one branch per "product" like spring and version
>>> "group".
>>>
>>> Branches would be
>>> spring-3.x
>>> spring-3.1.x
>>> spring-3.2.x
>>> ..
>>> Eventually also spring-3.1.3.x if we need to release the same spring 
>>> version a second time because of issues.
>>>
>>> Like you proposed as sub modules.
>>>
>>> Each spring branch would simply contain one directory
>>> spring
>>> with the structure for creating the spring feature. We could then
>>> create 
>>> one tag per actual release.
>>>
>>> This would have the advantage that each branch only contains exactly 
>>> what we intend to release.
>>>
>>> Honestly I personally would even consider putting the bundles there too
>>>
>>> so the bundles and the feature of each spring release reside together 
>>> and can be released in one step.
>>> As this was discussed this is only a personal remark.
>>>
>>> Christian
>>>
>>>
>>> On 08.02.2017 21:58, Krzysztof Sobkowiak wrote:
>>>> Hi
>>>>
>>>> The features repository is ready -
>>> https://git-wip-us.apache.org/repos/asf/servicemix-features.git. The
>>> structure looks similar to the bundles repository but managing the
>>> versions and separate feature modules is still open. One solution would
>>> be the bundles way, e.g. submodule for each minor version like this
>>>> spring-3.1.x
>>>> spring-3.2.x
>>>> ....
>>>> spring-4.1.x
>>>> spring-4.2.x
>>>> spring-security-3.1.x
>>>> activiti-5.19.x
>>>> activiti-6.0.x
>>>> .....
>>>>
>>>>
>>>> We could release next only the modules where we have fixed something
>>> (like in bundles). What do you think?
>>>> Kindly regards
>>>> Krzysztof
>>>>
>>>>
>>> -- 
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>
> -- 
> Krzysztof Sobkowiak (@ksobkowiak)
>
> JEE & OSS Architect, Integration Architect
> Apache Software Foundation Member (http://apache.org/)
> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
> Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

-- 
Krzysztof Sobkowiak (@ksobkowiak)

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

Reply via email to