In the past I have advocated many times that current strategy has some
serious flaws in its design. That it didn't make sense and that it bound
the project to a regime it wouldn't be able to maintain. We currently have,
besides the master, 3 active release branches:
1. r16, having our latest release from, whereabout some say that it will
be having its last release and others questioning that, while already new
commits were entered into,
2. r17, were we may have a first release from soon, and
3. r18, were we may have a first release from soon after the 1st of r17.
What we can expect is that as soon as a release appears in a new branch the
interest (from both adopters and contributors) in the old branch diminishes
rapidly/significantly.
Where other projects have a strategy of 'we need to do a new branch where
the Major changes as a result of some kind of paradigm shift that breaks
backward compatibility', we have a strategy of 'we need to a new branch
because the year changed, not because there is a major backward
compatibility issue'. IIRC, regarding code the only we had was the shift
from ant to gradle.
And the other paradigm shift we had was the shift from svn to git.
In the first approach the project will most likely have one active release
branch at a time. We, instead, have multiple active (r16,r17 and r18 in)
because of their relative longevity before the first/last release has been
established. Look at how we struggle with this strategy. And what a burden
it places on contributors to keep everything appropriately up to date.
We said we're going to do a new branch each year. Now someone stated
else-thread that we need to reconsider that strategy and change from
every-year to every-2-years. Are we, in 2 years from now, going to suggest
that we change to every-3-year strategy, when we're not hitting that
mark/moment?
Lets follow this generic strategy regarding releasing: we only increase the
major when we adopt a paradigm shift, and every release either only
increases the minor (except for CVE, which the PATCH number), like it is
intended with semver.
Then we could have a single release branch active as short as possible, and
not having one started before the community is determined (and works
towards) to close the active one. Our release cycles will be shorter, the
product will get more appeal which hopefully leads to more active
contributors and committers getting more issues
addressed/fixed/implemented/done, etc. leading to coming full circle to the
beginning of this sentence. Plus some of the other potential benefits
raised by Michael.
As for the aspect of roadmap as raised by Michel, I am inclined to agree.
But I caution the project (every community member) not to be to dogmatic
about what has been associated to a specific roadmap position-in-time. It
is an ambition to strive for. Not a rule set in stone. Succes regarding
this, hinges heavily on:
1. the project's commitment to take on specific development/feature
branches in a contributor's fork as branch in the project's official
repository, and
2. a clear definition of the 'Rules of Engagement' for both
non-privileged and privileged contributors.
Re 1: In essence saying: we - the project- are going to make this thing,
that is of community member X and resides in his own fork, and incorporate
it into our official repository with the intend to make it available to our
adopters in a future release.
Best regards,
Pierre Smits
*Proud* *contributor* (but without privileges)* of* Apache OFBiz
<
https://ofbiz.apache.org/>, since 2008
*Apache Trafodion <
https://trafodion.apache.org>, Vice President*
*Apache Directory <
https://directory.apache.org>, PMC Member*
Apache Incubator <
https://incubator.apache.org>, committer
Apache Steve <
https://steve.apache.org>, committer
On Sat, Feb 8, 2020 at 2:26 PM Michael Brohl <
[hidden email]>
wrote:
> Hi all,
>
> triggered by the discussions we had about new features, important
> changes and when/where to implement them and also Jacopo's question
> about the framework/plugins release strategy, here are some thoughts
> about our release strategy in general:
>
> In the past we created a release branch every year (with the exception
> of 2019), just starting where the trunk was at the time.
>
> Maybe we should start building a roadmap naming features we want to have
> in the next release and create the next release branch when we see it is
> the right time (looking at the *features*, not the time period). This
> would make more transparent and calculable to the users which changes
> are to expect in the next release and how the project evolves.
>
> A good roadmap would include a mix of core development tasks (making the
> framework better, new features in the applications and bugfixes). I can
> image a roadmap with certain goals might also motivate more contributors
> to work together on announced features and finish a release. It could
> also help to better organize community days and help organizing the
> development of long term changes (e.g. changes for a new deployment
> strategy, huge refactorings etc.).
>
> We should also better track the deprecation of features/API etc. so that
> we are able to better communicate when deprections will be introduced
> and executed.
>
> This all means a bit more planning and discussion in the community but
> could help to better join forces, work together on certain goals and
> provide a clearer vision about the project's roadmap in general.
>
> What do you think?
>
> Regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
>
Locked
smime.p7s (5K) 