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 <[email protected]> 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 > > >
