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 
<[email protected]> wrote:
On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
[email protected]> 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



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to