git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] Artemis Release cadence


It was actually something i meant to send last month. Wasnt related to the PR you mention.
Quite a few pr's from contributors included questions about release schedule. And without a clear cadence policy its not possible to give this. 
Also as a user having a clear cadence of a product makes it much easier to schedule around with upgrade planning etc.
I see such release cadence schedules on other open source projects and it makes expectations clear and just think it would be good to have one here, if we can agree one.


Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: Clebert Suconic <clebert.suconic@xxxxxxxxx> Date: 03/10/2018  18:41  (GMT+00:00) To: dev@xxxxxxxxxxxxxxxxxxx Subject: Re: [DISCUSS] Artemis Release cadence 
I have tried to do bug releases every 6 weeks.. sometimes it takes
longer depending on what's broken.


The thing that probaby caused you to send this was our discussion on
the PR? I think we are due for a 2.7.0, hence I thought about moving
into 2.7.0 and not doing 2.6.x any longer. WE can still do if someone
needs it.. but once we move into 2.7.0 we may not need 2.6.x any
longer.


I agree with cadencies.. however sometimes things are not as easy..
like.. right now we have a few broken tests (if you run an entire
testsuite), what would break a release.
On Wed, Oct 3, 2018 at 11:37 AM michael.andre.pearce
<michael.andre.pearce@xxxxxx.invalid> wrote:
>
> I see users asking sometimes when would bug fix y or feature x be available.
> I see alot of other apache projects have a clear feature and bug release cadence policy, which helps users know and expect what timescales to expect stuff.
> Also it stops problems of features being held up behind some big feature that could delay a release and users getting something theyre waiting for, as simply the item that didnt make it would slip into the next timed release cycle.
> Also for version patching what people should expect.
> It would be good if we could have something agreed like:
> Major release (breaking) avoided but once per year at most.
> Minor release (feature) every 4 months (jan,may,sept)
> Bug release every month (6 weeks) with current minor release -1 version being cherry picked to.
> Where we release no matter and simply what makes it in makes it, and anything missing because theres a timeline you know when it will be next.
> Thoughts?
>
>
>
>
>
> Sent from my Samsung Galaxy smartphone.



-- 
Clebert Suconic