Hi Jacques and everyone,
I think we agree to a large degree with your proposition in the below archived
thread Jacques. We see little advantage in upgrading our systems to newer
versions of OFBiz because the new features do not seem to be that major!
I would prefer slowing down the release cycle and to focus on accumulation of
enough features to warrant a release. Right now, both branches and releases
seem to be simply snapshots in time for the project, but I see no substantial
reward in upgrading nor do I see enough features to wet my appetite to play
around with the new releases.
For example, here are some milestones that would highly encourage me personally
to upgrade:
- Major overhaul of the UI (the bootstrap theme project for example)
- Addition of builtin documentation and completing the contextual help system
- Integration of third party systems (pentaho, CMSs, jackrabbit, etc ...)
- Substantial improvements to existing components (too much form/field clutter
in current design)
- Translations and internationalization improvement
- Change / upgrade of infrastructure (logging framework, transaction
management, build systems like gradle, JVM, etc ...)
My 2 cents
Taher Alkhateeb
----- Original Message -----
From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
To: dev@ofbiz.apache.org
Sent: Sunday, 21 December, 2014 5:26:40 PM
Subject: Re: Creating a new release branch before the end of the year
("release14.12")
Just as a reminder http://markmail.org/message/2wwueeciltqxon4r
Jacques
Le 21/12/2014 14:32, Pierre Smits a écrit :
> Did you get your wires crossed?
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Sun, Dec 21, 2014 at 11:07 AM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>>
>> Nothing prevent us to not create a relase branch in 2014 and only create
>> on in 2015 when ready.
>> Actually, due to Adrian's and my request, I believe we should rather go
>> that way
>>
>> This is as well a good argument to delay the branch creation, even if we
>> can expect to have all patches reviewed each time we need to create a
>> branch... but 60... !
>>
>> As I said above you invented this policy, we are free to skip a year
>>
