ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sharan Foga"<sharan.f...@gmail.com>
Subject Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches
Date Fri, 01 Jul 2016 07:01:33 GMT
Hi Pierre

I'd be happy summarise what my understanding is, but beforehand I'd like to point out that
any decision on this discussion thread isn't “the shared conclusion of the PMC”.
The discussion was raised on this list specifically to get feedback from our community and
it's from that feedback that any conclusions are drawn or decisions taken . 

My understanding is that there was general consensus for the following:

- There would be no more releases from 13.07 so the current release that is out would be the
last one in that series

- We would not backport any of the gradle changes into the 14.12. or 15.12 branches because
it would cause instability

- We would leave 14.12 and 15.12 as unreleased branches as they are now (and not make them
into releases as to do that we would need to remove all the jar files and this would create
instability). 

- We would focus on implementing the gradle changes into the trunk and then creating and stabilising
a 16.x release ASAP

- The benefits for our community are that developers and service providers will still have
access to the complete codebase for 14.12 and 15.12 including the special purpose components
to be able to support their client base.

I suggested taking the discussion to the development list so that we can talk in more detail
about the release planning and also the duration of support the unreleased branches. This
again, will be a community discussion and decision. Once we have these details we can communicate
them to our user community.

This was my understanding, so if anyone has a another interpretation or understanding then
please feel free to comment.

Thanks
Sharan

On 2016-06-30 15:40 (+0200), Pierre Smits <pierre.smits@gmail.com> wrote: 
> It seems to me that Sharan is jumping the fence a bit to soon. Multiple
> suggestions have gathered support.
> This makes any 'this solution', without repeating what that solution is ,
> multi-interpretable and would not only continue the discussion. But also
> the confusion.
> 
> I suggest to repeat once more what the shared conclusion of the PMC is
> regarding this discussion, so that the entire community can anticipate to
> what is coming in the near future, and what the PMC will take to the dev ml
> for planning purposes regarding the short term actions.
> 
> Best regards,
> 
> 
> Pierre Smits
> 
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
> 
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
> 
> On Thu, Jun 30, 2016 at 2:26 PM, Sharan Foga <sharan.foga@gmail.com> wrote:
> 
> > Hi Everyone
> >
> > Thanks very much for the feedback. I'm glad that this solution will
> > resolve our current problems without taking away any functionality from the
> > service providers or developers that are using the unreleased branches.
> >
> > Our next step will be to create and stabilise the 16.x release ASAP so
> > that our user community will have another release available. This will
> > become our top priority.
> >
> > I suggest that we close off the discussion now as I think we've had quite
> > a detailed discussion and it looks like we have come to a consensus and
> > resolved the issues. We can now take the discussion back to the dev list
> > where we can talk about the timings, release roadmap and also the support
> > timeframe for the unreleased branches.
> >
> > Thanks
> > Sharan
> >
> > On 2016-06-30 11:01 (+0200), Michael Brohl <michael.brohl@ecomify.de>
> > wrote:
> > > Great idea, +1
> > >
> > > Michael Brohl
> > > ecomify GmbH
> > > www.ecomify.de
> > >
> > >
> > > Am 30.06.16 um 09:05 schrieb Sharan Foga:
> > > > Thanks for the response -Jacopo. (You posted a minute before I did!)
> > > >
> > > > Anyway I think that I might have an idea that could solve our problem
> > – let's just leave 14.12 and 15.12 as unreleased branches.
> > > >
> > > > The jar issue is only an issue if we want to convert the unreleased
> > branches into a release. Unreleased they can contain the jar files and the
> > special purpose components etc – but if we want to release them then
we
> > need to fix the jar file problem before it can be released.
> > > >
> > > > Christian mentions that people are using the unreleased branches, so
> > by leaving them unreleased, we are actually giving our users something that
> > can help them move from 13.07.
> > > >
> > > > So I suggest that we seriously consider leaving 14.12 and 15.12 as
> > unreleased branches.
> > > >
> > > > For the next point – I think our next release should be
the 16.x –
> > so that means that we are not backporting any changes and can take a branch
> > directly from the trunk once the gradle changes have been applied.
> > > >
> > > > Comments anyone?
> > > >
> > > > Thanks
> > > > Sharan
> > > >
> > > >
> > > > On 2016-06-30 07:25 (+0200), Jacopo Cappellato <
> > jacopo.cappellato@hotwaxsystems.com> wrote:
> > > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > >> christian.geisert@isu-gmbh.de> wrote:
> > > >>
> > > >>> ...
> > > >>> My proposal is to release 14.12 ASAP, after that dropping 13.07
and
> > then
> > > >>> trying to do a release 16.x with Gradle. And a release of 15.12in
> > > >>> between wouldn't be bad either ;)
> > > >>>
> > > >>>
> > > >> Thank you Christian.
> > > >> Your proposal makes sense but the problem is that we will not be able
> > to
> > > >> release (14.12, 15.12 etc...) until we have removed all the jars from
> > the
> > > >> distribution, and implementing this in the branches will require some
> > > >> layout changes that will bring instability: the releases will be
> > delayed
> > > >> regardless and if we want to implement two different mechanisms for
> > > >> downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> > > >> codebases will become rather different and more difficult to
> > maintain; and
> > > >> the extra effort will have to be backed up by the interested users.
> > We have
> > > >> to consider these aspects and do a reality check on resources before
> > moving
> > > >> in any direction.
> > > >>
> > > >> Jacopo
> > > >>
> > >
> > >
> > >
> >
> 

Mime
View raw message