logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Versioning/branching after 2.0 release
Date Sun, 13 Jul 2014 20:41:07 GMT
I'm so used to git, I forgot that tags were almost equivalent to branches
as it is. No need to overly complicate things, then. Branches are neat
places to put up some code that isn't ready for the trunk, but you still
want it out there for anyone else to do as they wish with it.


On 13 July 2014 14:59, Ralph Goers <rgoers@apache.org> wrote:

> We have a tag so a branch can be made at any time. But I don't know of any
> ASF project that does "release maintenance" - everybody just does fixes as
> we have here and then creates a new release with whatever fixes and
> enhancements are there. The only exceptions to this would be security bugs
> or critical fixes, but a lot of times those just force a release as soon as
> the fix is committed.
>
> Ralph
>
> On Jul 13, 2014, at 12:07 PM, Matt Sicker <boards@gmail.com> wrote:
>
> I think it's a good idea to keep old release branches for security fixes
> and such. Otherwise, mainline trunk development seems to make sense to me.
>
>
> On 13 July 2014 10:22, Gary Gregory <garydgregory@gmail.com> wrote:
>
>> FYI http://semver.org/
>>
>> Gary
>>
>>
>> -------- Original message --------
>> From: Gary Gregory
>> Date:07/13/2014 09:59 (GMT-05:00)
>> To: Log4J Developers List
>> Subject: RE: Versioning/branching after 2.0 release
>>
>> I think we just work as usual in trunk  and release when ready and use
>> semantic versioning. No need to maintain branches unless absolutely
>> necessary. API breakage is only for major versions. We need to decide if
>> that is just for the API module or all modules.
>>
>> Gary
>>
>>
>> -------- Original message --------
>> From: Remko Popma
>> Date:07/13/2014 09:39 (GMT-05:00)
>> To: Log4J Developers List
>> Subject: Versioning/branching after 2.0 release
>>
>> After the 2.0 release, how are we going to do versioning?
>>
>> One idea is to have 2.0.x releases with bugfixes only, where new features
>> and any API changes would go into a 2.1 release.
>>
>> Another way of doing this is to simply have a 2.1 release next containing
>> both bugfixes and new features as well as API changes if any.
>>
>> And perhaps there are other ways...
>>
>> I don't have a strong preference about this but it may be good to discuss
>> this since it may determine how we do branching going forward.
>>
>> Thoughts?
>>
>> Remko
>>
>
>
>
> --
> Matt Sicker <boards@gmail.com>
>
>


-- 
Matt Sicker <boards@gmail.com>

Mime
View raw message