cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Cayenne release policy thoughts
Date Sun, 29 Apr 2018 06:20:01 GMT
> We've typically never added a feature to a x.y release once it is final. But that doesn't
have to be a hard and fast rule. For example, we could decide to release 4.0.1 with new features
as long as no existing functionality is broken. 

I don't see a problem with that even under the current scheme. It is more of a cost/benefit
thing to the core devs, so usually backporting is limited to bug fixes. I'd say in practice
someone will need to lobby (or send a PR) for a feature X to be ported to an N - M release.


> 2. Faster release cycle signifies project health 


Yep.

> 3. Separately versioned modeler
> If the modeler was able to save older versions of the schema, then there would be no
need to maintain older branches for that app and it could move forward more quickly without
maintenance of old branches.

That's be great in theory, though in practice it will actually result in *more* maintenance
and testing, as we'd need to handle the whole spectrum of (possibly conflicting) model capabilities
in the same version of the tool. We may try to provide "Save as version N -M" option though.
Not sure if that is a helpful scenario.

> 4. More lightweight alpha releases
> 
> To make it quick and easy to cut development milestones, can we skip the PMC voting process
and go for something slightly less formal. Betas and release candidates would have the full
review process. Or even just have an expedited 24 hour voting period.

I don't think we can do this as an Apache project. All releases must be approved by the PMC,
and there's no wiggle room on that. IIRC there was even pushback against posting direct CI
links on the project website.

Andrus




> On Apr 28, 2018, at 2:50 PM, Aristedes Maniatis <ari@maniatis.org> wrote:
> 
> 1. More releases means more patching and releasing of bug fixes to different branches.
> 
> To understand the impact of this we need to consider what a new release means and how
many old releases we need to support.
> 
> * API change
> 
> * new features added
> 
> * deprecated methods removed
> 
> We've typically never added a feature to a x.y release once it is final. But that doesn't
have to be a hard and fast rule. For example, we could decide to release 4.0.1 with new features
as long as no existing functionality is broken. Or conversely we could call it 4.1, but no
longer provide bug fixes for 4.0, requiring users to upgrade to get those fixes as long as
that upgrade doesn't require the user to change any code in their app.
> 
> So what is the balance between providing old bug fix releases and being able to move
forward more quickly? saltstack is an example of a software project that adds new features
from 2018.3.0 to 2018.3.1, but doesn't change existing functionality.
> 
> 
> 2. Faster release cycle signifies project health
> 
> Developers will look at the number of releases per year as a measurement of project health.
So more releases are a good thing.
> 
> 
> 3. Separately versioned modeler
> 
> If the modeler was able to save older versions of the schema, then there would be no
need to maintain older branches for that app and it could move forward more quickly without
maintenance of old branches.
> 
> 
> 4. More lightweight alpha releases
> 
> To make it quick and easy to cut development milestones, can we skip the PMC voting process
and go for something slightly less formal. Betas and release candidates would have the full
review process. Or even just have an expedited 24 hour voting period.
> 
> 
> Just a few thoughts. For our own projects we've been using milestone Cayenne releases
in production for as long as I can remember, so I certainly like the idea of formalising them
into shorter release cycles, particularly now that most of the disruptive (to users) changes
in the API over the last years are probably behind us.
> 
> 
> Ari
> 
> 
> 
> On 28/4/18 8:50pm, Nikita Timofeev wrote:
>> Hi all,
>> 
>> Wanted to share my thoughts about our release policy.
>> 
>> I think it will be better for Cayenne to reduce scopes of future
>> releases, as not many users are ready to use milestone or even beta
>> releases. At the same time we can't create final release if there are
>> a lot of new things, because of long feedback cycle.
>> Good example of this problem is 4.0 version that started 5 years ago
>> (as a 3.2 back then) and still not finished. Even Java itself released
>> faster now :)
>> 
>> As for nearest plans, 4.1 already have some nice features (like
>> field-based data objects or recently added completely new dbimport
>> interface in Modeler), so I think we can target it to feature freeze
>> after M2.
>> 
>> And we can already start to push new tasks into next (4.2?) version or
>> even think about several versions ahead.
>> 
>> So any thoughts about overall shorter release cycles or 4.1, 4.2 release plans?
>> 


Mime
View raw message