karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <anpie...@gmail.com>
Subject Re: Maintenance "Policy"
Date Mon, 03 Jan 2011 12:58:50 GMT
Basically I've no problems with that; but I think we really should
provide hudson builds (and automate deploys to apache-snapshot repos)
for all supported branches, don't you think?

kind regards,

On Mon, Jan 3, 2011 at 1:51 PM, Jamie G. <jamie.goodyear@gmail.com> wrote:
> Hi Andreas,
> It doesn't appear that we have a written policy for Karaf maintenance.
> In general we reserve trunk for new development, and the patch
> branches for bug fixes (and the rare improvement that does not break
> backwards compatibility).
> Right now the current active support is on the 2.1.x branch and main
> trunk. After the 2.2.0 release occurs then we will have the 2.1.x,
> 2.2.x, and the new trunk as active lines. I do not believe we have a
> planned discontinue of support for the earlier releases, if such was
> to be considered I'm sure that we would have an open discussion and
> vote on the matter. Personally, as long as bug fixes are being
> submitted to past branches I'm more than happy to spin up a release
> candidate for consideration & vote.
> If anyone else knows better on the subject please help clarify the matter :)
> Cheers,
> Jamie
> On Thu, Dec 30, 2010 at 3:36 AM, Andreas Pieber <anpieber@gmail.com> wrote:
>> Hey,
>> I've seen that there had been a commit to karaf-2.0.x branch; do we still
>> support it? What is the maintenance "policy" for karaf? Which versions do we
>> officially support? Only the latest stable release (e.g. 2.1.x for now)?
>> Where do we "have" to back-port bug-fixes... E.g. if I find a problem in 2.1.2;
>> do I have to also fix it in 2.0.x (if it exists there)?
>> In addition to this question: IMHO we should also setup Hudson build targets for
>> all "officially" supported versions to make bug-fixes easier and faster
>> available via snapshots in the apache snapshot repository.
>> Any ideas? Are there already guidelines documented anywhere?
>> kind regards,
>> andreas

View raw message