General OFBiz release strategy

[Michael Brohl <mi...@ecomify.de>]

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

Re: General OFBiz release strategy

[Pierre Smits <pi...@apache.org>]

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 <mi...@ecomify.de>
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
>
>
>

Re: General OFBiz release strategy

[Jacques Le Roux <ja...@les7arts.com>]

Le 14/02/2020 à 16:46, Nicolas Malin a écrit :
> Hi,
> On 08/02/2020 14:25, Michael Brohl wrote:
>> Hi all,
>>
>> [...]
>> 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.).
>>
>> What do you think?
>
> I'll always stay in favor of a fixed time release branchas rules like musical paper who encourages us to move forward.
>
> Perhaps we willincrease the space between each release to two years,which seems to be more realistic.
>
> On the roadmap concept, personally I don't believe in it, except forgiving us a good reason not to follow it. I'm being sarcastic but I will 
> explain. We mostly commit to OFBiz some problematic or improvement that we realized from production deployment after a process to ensure they will 
> be a real addedvalue for the community.
>
> Set a roadmap to define the next OFBiz release implythat current projects(I talk about customer projectsfrom each society) follow or match the 
> roadmap and intrinsically we should achieve a goal to create an official release (that can be never done).
>
> I more attachedto the principle concept (or golden rules, nameitas you wish) that will allowto see if a commit would not be in contradiction with 
> them. Some principles: need to be extensible by plugins, move old language code to up to date code, respect coding rules, make it simple, ...
>
> This open more space for contributions while alsodefininga minima the way that we wish to follow, timed by releases.
>
> Just a last point, Sharan has been started a quality works on OFBiz roadmap [1] that we never continue. I talk about that not as reproach but more 
> as aninteresting try that unfortunately didn't match with how we works day-to-day
>
> Nicolas
>
> [1] https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Framework+Roadmap

+1 here a list of attempts in the past:

https://cwiki.apache.org/confluence/display/OFBIZ/4.x+Proposed+Roadmap+Items

https://cwiki.apache.org/confluence/display/OFBIZ/Sharan+-+Documentation+WIP (see children pages in the left panel)

https://cwiki.apache.org/confluence/display/OFBIZ/New+Features+Roadmap+-+Living+Document

If we would really want to do that I think the later is the simplest realistic one. But I believe, it would be wasted time again and I know what I'm 
talking about.
We need to be realistic. It's impossible to "manage" an open source project, at least one like OFBiz. I think Nicolas explained very well why...

Jacques

Re: General OFBiz release strategy

[Nicolas Malin <ni...@nereide.fr>]

Hi,
On 08/02/2020 14:25, Michael Brohl wrote:
> Hi all,
>
> [...]
> 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.).
>
> What do you think?

I'll always stay in favor of a fixed time release branchas rules like
musical paper who encourages us to move forward.

Perhaps we willincrease the space between each release to two
years,which seems to be more realistic.

On the roadmap concept, personally I don't believe in it, except
forgiving us a good reason not to follow it. I'm being sarcastic but I
will explain. We mostly commit to OFBiz some problematic or improvement
that we realized from production deployment after a process to ensure
they will be a real addedvalue for the community.

Set a roadmap to define the next OFBiz release implythat current
projects(I talk about customer projectsfrom each society) follow or
match the roadmap and intrinsically we should achieve a goal to create
an official release (that can be never done).

I more attachedto the principle concept (or golden rules, nameitas you
wish) that will allowto see if a commit would not be in contradiction
with them. Some principles: need to be extensible by plugins, move old
language code to up to date code, respect coding rules, make it simple, ...

This open more space for contributions while alsodefininga minima the
way that we wish to follow, timed by releases.

Just a last point, Sharan has been started a quality works on OFBiz
roadmap [1] that we never continue. I talk about that not as reproach
but more as aninteresting try that unfortunately didn't match with how
we works day-to-day

Nicolas

[1]
https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Framework+Roadmap