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?
