HI Charl, All, To add to the thoughts shared by Sharan, the release branch 14.12 also brought back components excluded in the 13.07 branch and releases. Our release branches are not only for use of developers, but are intended to cut releases from.
Also, the privileged contributors have - in several cases - also backported improvements from trunk into release branches. Sharan is correct regarding risk! Without a shared agreement - on conclusions derived from discussion threads - by the contributors with binding powers (PMC Members), any privileged contributor (those contributors with commit privileges) can do whatever they want in any of the branches. They can continue to add bug fixes to branches. Also, any contributor can continue to register issues regarding specific branches/releases and provide patches to fix those. This helps adopters to both minimise risk as well as stay connected to the project: They can use JIRA as a risk reporting and monitoring mechanism and the projects code repos (ASF SVN/Git, Github) as code source for those aspects of their OFBiz implementation that they don't want to have control over, but leave it to their benevolent privileged contributors. I trust this helps. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Sat, Jul 2, 2016 at 11:28 AM, Sharan Foga <sharan.f...@gmail.com> wrote: > Hi Charl > > I'm not a developer – so I hope that others will also respond on this with > their opinions too. > > My thoughts are that you do have the option of basing your POC on either > of our two branches. Our branches are for the use of developers because it > sounds like you are going to do some changes. I also think that a lot of > developers base their work on our branches rather than the release itself. > > The 14.12 branch was created in December 2014 and contains new features > not present in 13.07. We have backported bug fixes to it, so it has been > maturing and stabilising for over 18 months and would have been our next > release. Also recent OFBiz fork announced this mailing list is based on our > 14.12 branch. > > Our 15.12 branch was created in December 2015 and once again includes new > features not present in 14.12 and any bug fixes. This has been maturing and > stabilising for 6 months. > > I think it is all about risk. Depending on what you want to achieve with > your POC, then I suspect that you could still possibly go ahead using 14.12 > instead of 13.07 if you wanted to, so perhaps take a look at the > differences between 14.12 and 13.07 to see if it affects what you were > wanting to do. > > Thanks > Sharan > > On 2016-07-01 15:15 (+0200), Charl Bouwer <zarach...@gmail.com> wrote: > > Hi all > > > > Where does it leave a new user that is planning to become a contributor. > I > > am past the R&D stage and meeting my business partner next week to inform > > him I already have 2 possibly 3 clients that is interested in a POC. In > the > > next month I am building a POC based on the 13.07 build. > > > > I was already able to setup eclipse with debugging enabled and have both > > the trunk and 13.07 SVN repositories. I am busy doing the same with > > Intellij/GIT setup, my preferred IDE environment. I am planning to use > the > > POC to customise for my region, including the initial seed data. Which in > > turn will lead to me working on the multi tenancy aspect. > > > > Should I continue with 13.07 as base with the intention to have a > > production server in the next say 3-6 months. > > Any suggestions on how I should proceed from here? > > > > Sorry I only subscribed to the dev-list today > > > > Thanks > > Charl > > > > > > On Fri, Jul 1, 2016 at 9:01 AM, Sharan Foga <sharan.f...@gmail.com> > wrote: > > > > > 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.sm...@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.f...@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.br...@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.cappell...@hotwaxsystems.com> wrote: > > > > > > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert < > > > > > > >> christian.geis...@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 > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
