I think a bit about this today. There is one alternative. We could decide to let the future R13.07 releases as is the R13.07.01, ie without the
specialpurpose components but ecommerce. And we would freeze a new branch where we would keep some of the specialpurpose components disabled, but not
all, as Jacopo suggested.
Advantages: it's easy to do, we have not to collect and apply the specialpurpose bug fixes in trunk since 12329808. The R13.07 releases will be
consistent, no need to explain to our users what happened between R13.07.01 and R13.07.02
Drawbacks: when we will deliver our next freezed branch releases our users could ask why now some of the specialpurpose components are back. But this
is easy to explain. Of course the R13.07 releases will always miss the specialpurpose components but ecommerce.
We need to face it, removing the specialpurpose components but ecommerce was not a good idea. But putting them back in is a lot of work. So if our
users really want to use the R13.07 releases will some specific the specialpurpose components it would be their own responsibility.
Opinions?
Jacques
Le 30/11/2014 19:02, gil portenseigne a écrit :
Hi,
I think it's the good way to do (not trunk, but branch state) !
Gil
Le 30/11/2014 16:56, Jacques Le Roux a écrit :
Hi,
Initially I wanted to write a complete email with several concerned points. I changed my mind and prefer to discuss each point in separated emails,
though in the same thread. It will be easier.
The 1st point which comes to my mind is what to exactly put back in release
branch.
We can't put the current trunk HEAD state, because we will face the rule which says that we shall not add new features in release branches. And
obviously there are some since we freezed this branch and moreover few (at least EntityQuery) are blockers. So I guess we should put the state of
the specialpurpose components in trunk when the branch was freezed http://svn.apache.org/viewvc?view=revision&revision=r1505933 and then add the
bug fixes since https://issues.apache.org/jira/issues/?filter=12329808
We cannot rely only on Jira, at least it's a start.
Jacques
