Hi all,

Just wanted to bump up this old thread [1] where we discussed about the release 
strategy.
We concluded that it would not be a good idea to have a higher release 
frequency but after graduation (to keep the pressure low on the IPMC).

Thus, I want to continue the discussion.
As we are pretty heavy users of PLC4X I would like to see regular releases with 
a  frequency of 1 – 2 months (at least for now, where a lot happens).

What are others opinions and thoughts?

Julian

On 2019/03/10 18:07:46, Julian Feinauer 
<[email protected]<mailto:[email protected]>> wrote:
> Oh and what about some opc ua support for the 0.4.0 release (looking towards 
> Mathias and Tim....)?>
>
>
>
> :)>
>
>
>
> Julian>
>
>
>
> Von meinem Mobiltelefon gesendet>
>
>
>
>
>
> -------- Ursprüngliche Nachricht -------->
>
> Betreff: AW: [DISCUSS] Release Strategy for future releases>
>
> Von: Julian Feinauer>
>
> An: [email protected]<mailto:[email protected]>>
>
> Cc:>
>
>
>
> Hi Tim,>
>
>
>
> Sounds good to extend the group of release managers.>
>
> I think there is already a release prepared in Jira but I agree to polish the 
> Jira issues a bit and assign the release field so that we have an idea what 
> we want to have in there upfront.>
>
>
>
> Julian>
>
>
>
> Von meinem Mobiltelefon gesendet>
>
>
>
>
>
> -------- Ursprüngliche Nachricht -------->
>
> Betreff: Re: [DISCUSS] Release Strategy for future releases>
>
> Von: Tim Mitsch>
>
> An: [email protected]<mailto:[email protected]>>
>
> Cc:>
>
>
>
> Hello everybody,>
>
>
>
> I'll agree with Chris as well as with Julian ... think lots of people are 
> under heavy load in incubator so high release frequency won't be the best 
> solution as long as we are an incubating project.>
>
> On the other hand we should take care about not releasing in too less 
> frequency to make interested people more interested in what we're doing and 
> make feature available as early as possible.>
>
> As already said ... I think we should create a more or less regular 
> release-interval when we are graduated.>
>
>
>
> As I had a look on Julian doing 0.3.1 release procedure I think I can do the 
> RM for next release which I think will be 0.4.0 (maybe end of April or 
> beginning of may).>
>
> If there is nothing against it I'll start to prepare a feature list and 
> opening a new topic on mailing-list for that as well as creating the 
> regarding jira-tickets.>
>
>
>
> Best>
>
> Tim>
>
>
>
> Am 06.03.19, 21:55 schrieb "Julian Feinauer" 
> <[email protected]<mailto:[email protected]>>:>
>
>
>
>     Hey Otto,>
>
>
>
>     fair point. I think we should to decide a new release strategy. But if we 
> consider to keep it as it is now we should not have to vote.>
>
>
>
>     Or?>
>
>
>
>     Julian>
>
>
>
>     Von meinem Mobiltelefon gesendet>
>
>
>
>
>
>     -------- Ursprüngliche Nachricht -------->
>
>     Betreff: Re: [DISCUSS] Release Strategy for future releases>
>
>     Von: Otto Fowler>
>
>     An: [email protected]<mailto:[email protected]>,Christofer Dutz>
>
>     Cc:>
>
>
>
>     Shouldn’t you call an official vote for something like this?>
>
>
>
>
>
>     On March 6, 2019 at 15:29:18, Christofer Dutz 
> ([email protected]<mailto:[email protected]>)>
>
>     wrote:>
>
>
>
>     Big +1 for that ;-)>
>
>
>
>     Chris>
>
>
>
>
>
>     Am 06.03.19, 21:26 schrieb "Julian Feinauer" 
> <[email protected]<mailto:[email protected]>>:>
>
>
>
>
>
>     Hi Chris,>
>
>
>
>     No offense. I agree that we should not stress those lovely people more 
> than>
>
>     necessary.>
>
>     So we keep our aim on 0.4 (with whatever accumulates till then) for now 
> and>
>
>     start regular releases when graduated.>
>
>
>
>     Is this a plan?>
>
>
>
>     Julian>
>
>
>
>     Von meinem Mobiltelefon gesendet>
>
>
>
>
>
>     -------- Ursprüngliche Nachricht -------->
>
>     Betreff: Re: [DISCUSS] Release Strategy for future releases>
>
>     Von: Christofer Dutz>
>
>     An: [email protected]<mailto:[email protected]>>
>
>     Cc:>
>
>
>
>     Hi Julian,>
>
>
>
>     I would +1 this, but please have one thing in Mind ... every release we 
> do>
>
>     requires us to check it (of course) ... but also we have to have people 
> in>
>
>     the Incubator also validate these releases.>
>
>     Some people there are under heavy load and I would not like to increase>
>
>     this load too much.>
>
>
>
>     But how about starting with that as soon as we have left the incubator? I>
>
>     would really like that.>
>
>
>
>     Chris>
>
>
>
>
>
>     Am 06.03.19, 09:15 schrieb "Julian Feinauer" 
> <[email protected]<mailto:[email protected]>>:>
>
>
>
>
>
>     Hi all,>
>
>
>
>     perhaps some may find this email too early (as we are still in the 
> process>
>
>     of doing a Release) but I want to ask / discuss about how we plan to do>
>
>     releases in the future.>
>
>     Up till now, they were were infrequent due to the early stage of the>
>
>     project but now I think we have stabilized well, we have stable APIs and>
>
>     mostly new features coming in.>
>
>     One problem we had most of the time was, that we had to work on “forked>
>
>     releases” because the last official release lacked (newer) features we>
>
>     needed.>
>
>     Thus, I suggest that we start to release more often or even on a regular>
>
>     schedule (like e.g. Calcite does it) to ship the new features soon.>
>
>     Also this could help us, to teach more people how to release / rm.>
>
>
>
>     As we are mostly shipping features, there’s nothing speaking against 
> doing>
>
>     minor (i.e. compatible) releases which makes it really easy for users to>
>
>     update.>
>
>     Perhaps, we could aim for monthly releases (if we have things to release)>
>
>     and already start the setup for that. I am really eager to get the 
> PLC4X-88>
>
>     (Triggered Scraper) merged and then shipped!>
>
>     Next would then be 0.3.2 in early April.>
>
>
>
>     What do you think of that concrete and more general?>
>
>
>
>     Julian>
>
>
>
>     PS.: If we move forward with graduation the release process is also>
>
>     becoming a bit easier, as there’s only one vote necessary (and no longer>
>
>     the second vote from the IPMC)>
>
>
>
>
>
>

Reply via email to