You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Davide Giannella <da...@apache.org> on 2019/03/27 14:19:54 UTC
[SUMMARY] Branching and release
Good afternoon everyone,
here's a summary of what we discussed in previous threads:
https://lists.apache.org/thread.html/768807eed3379dc08921a1510264136ffe4a7a1230d9ca7881cc0a59@%3Coak-dev.jackrabbit.apache.org%3E
https://lists.apache.org/thread.html/c29415060be41938bdb7bfeac3e79a5d7efaf51dff84461657dff462@%3Coak-dev.jackrabbit.apache.org%3E
*Strategies*
- trunk will be considered stable
- only releases from trunk other than existing branches
- any previous release from trunk will be automatically deprecated
*Branching*
Branching will not happen other than in specific circumstances. Such as,
but not limited to:
- incompatible API changes
- incompatible JVM changes
- updates to dependencies that breaks backward compatibility
In short: most probably it will always be around non-backward-compatible
changes
Anyhow in such cases the branching is not automatic and will be
discussed between PMCs a best course of actions. Alternatives may be a
different way to implement something breaking.
*Frequency*
Every two months with room, as usual, for early cuts in case or urgent
needs.
*Version Numbers*
- Released versions will be in the format of `Major.Minor.Patch` where,
as rule of thumb we will increase
1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible
manner, and
3. PATCH version when you make backwards-compatible bug fixes.
- We'll keep the even/odd schema
- Any new official release will be always even: 1.12.0, 1.14.0, 1.16.0,
..., 1.124.0
- A release will always be with a patch number (the last part) of `.0`.
This ease OSGi deployments.
- Diagnostic builds will be cut with the odd version and `-Rxxx` such as
1.15-R12345.
- In case of branching the increased part will always be the PATCH so:
1.16.0, 1.16.1, 1.16.2, etc.
- In case of branching the diagnostic build will follow the current
pattern: `1.16.5-R12345`
If I missed anything or any objections please reply. I will update docs
in the near future.
Cheers
Davide
Re: [PROPOSAL] Branch 1.22.0
Posted by Julian Reschke <ju...@gmx.de>.
On 29.01.2020 15:03, Julian Reschke wrote:
> ...
> The concrete steps would be:
>
> - create the branch based on the tag 1.22.0
> - flip the default for lazy loading of Lucene index files
> - backport selected changes from trunk (such as related to yesterday's CVE)
> - release 1.22.1
> - (later on) retire 1.10.*
> ...
Hi there,
in the meantime, all of this was done except the last step. In our
downstream project, we have now successfully replaced Oak 1.10.8 with
Oak 1.22.2, so I believe we can retire the 1.10 branch, recommending
people to use 1.22 instead.
I'm planning to do this at the end of the week; please let me know if
that would cause any problems.
Best regards, Julian
Re: [PROPOSAL] Branch 1.22.0
Posted by Julian Reschke <ju...@gmx.de>.
On 29.01.2020 18:45, Angela Schreiber wrote:
> Hi Julian
>
> Given the fact that with the CVE announced yesterday, we encouraged
> everyone using 1.12.0 - 1.22.0 to upgrade to 1.24.0, your second variant
> (releasing 1.26.0 shortly and branching 1.24.0 instead) would feel a bit
> better to me... for the sake of communication consistency.
>
> That's as far as the security area is concerned the only significant
> diff between 1.22 and 1.24.
>
> Kind regards
> Angela
Well, we also encouraged people on 1.10.* to upgrade to a newer version
of 1.10.*, and that's what'll be replaced by that branch.
Best regards, Julian
Re: [PROPOSAL] Branch 1.22.0
Posted by Angela Schreiber <an...@adobe.com.INVALID>.
Hi Julian
Given the fact that with the CVE announced yesterday, we encouraged everyone using 1.12.0 - 1.22.0 to upgrade to 1.24.0, your second variant (releasing 1.26.0 shortly and branching 1.24.0 instead) would feel a bit better to me... for the sake of communication consistency.
That's as far as the security area is concerned the only significant diff between 1.22 and 1.24.
Kind regards
Angela
________________________________
From: Julian Reschke <ju...@gmx.de>
Sent: Wednesday, January 29, 2020 4:44 PM
To: oak-dev@jackrabbit.apache.org <oa...@jackrabbit.apache.org>; Angela Schreiber <an...@adobe.com>
Subject: Re: [PROPOSAL] Branch 1.22.0
On 29.01.2020 16:25, Angela Schreiber wrote:
> Hi Julian
>
> Not sure I got the explanation regarding 'why not branching 1.24.0' in relation to the required changes regarding OAK-7947. According to jira that issue got fix in 1.12.0<https://issues.apache.org/jira/issues/?jql=project+%3D+OAK+AND+fixVersion+%3D+1.12.0>, right? So isn't the same 'flip lazy loading of lucene index' needed irrespective of whether we branch 1.22.0 or 1.24.0? And wouldn't the same 'newer' question you explained below also apply when branching 1.22.0?
>
> I guess I am missing one piece in that reasoning... otherwise I don't have a strong preference and would be find with the proposal.
>
> Angela
The default would need to be flipped in any case, right.
The only difference is that if we released 1.24.1 instead if 1.22.1,
users of 1.24.0 might incorrectly assume that this is a release they
should upgrade to.
That of course could be addressed by quickly releasing 1.26.0 as well,
but as we just released 1.24.0 yesterday...
Best regards, Julian
Re: [PROPOSAL] Branch 1.22.0
Posted by Julian Reschke <ju...@gmx.de>.
On 29.01.2020 16:25, Angela Schreiber wrote:
> Hi Julian
>
> Not sure I got the explanation regarding 'why not branching 1.24.0' in relation to the required changes regarding OAK-7947. According to jira that issue got fix in 1.12.0<https://issues.apache.org/jira/issues/?jql=project+%3D+OAK+AND+fixVersion+%3D+1.12.0>, right? So isn't the same 'flip lazy loading of lucene index' needed irrespective of whether we branch 1.22.0 or 1.24.0? And wouldn't the same 'newer' question you explained below also apply when branching 1.22.0?
>
> I guess I am missing one piece in that reasoning... otherwise I don't have a strong preference and would be find with the proposal.
>
> Angela
The default would need to be flipped in any case, right.
The only difference is that if we released 1.24.1 instead if 1.22.1,
users of 1.24.0 might incorrectly assume that this is a release they
should upgrade to.
That of course could be addressed by quickly releasing 1.26.0 as well,
but as we just released 1.24.0 yesterday...
Best regards, Julian
Re: [PROPOSAL] Branch 1.22.0
Posted by Angela Schreiber <an...@adobe.com.INVALID>.
Hi Julian
Not sure I got the explanation regarding 'why not branching 1.24.0' in relation to the required changes regarding OAK-7947. According to jira that issue got fix in 1.12.0<https://issues.apache.org/jira/issues/?jql=project+%3D+OAK+AND+fixVersion+%3D+1.12.0>, right? So isn't the same 'flip lazy loading of lucene index' needed irrespective of whether we branch 1.22.0 or 1.24.0? And wouldn't the same 'newer' question you explained below also apply when branching 1.22.0?
I guess I am missing one piece in that reasoning... otherwise I don't have a strong preference and would be find with the proposal.
Angela
________________________________
From: Julian Reschke <ju...@gmx.de>
Sent: Wednesday, January 29, 2020 3:03 PM
To: oak-dev@jackrabbit.apache.org <oa...@jackrabbit.apache.org>
Subject: [PROPOSAL] Branch 1.22.0
Hello team.
When we introduced the new release/branching strategy last March, it was
clear that we might have to create branches once incompatible changes
happen.
Now is the time. (Well, soon).
<https://issues.apache.org/jira/browse/OAK-7358> will make incompatible
changes (so that we can compile & run on Java 14). I therefore propose
to create a branch, from which we can continue to cut releases that are
fully compatible with 1.22.0.
The good news is that we have confirmed that 1.22.* can be used as
drop-in replacement for 1.10.*, thus at the same time (or close to it)
we could retire 1.10.
The only issue we found was due to slightly changed system behaviour
when lazy loading of Lucene index files is in effect. I would therefore
propose to disable that feature in the first release from that branch
(see <https://issues.apache.org/jira/browse/OAK-7947>, there's a system
property for this, we would just have to flip the default value).
(And yes, this proposal is equivalent to just replay *any* change made
in trunk to 1.10.*)
The concrete steps would be:
- create the branch based on the tag 1.22.0
- flip the default for lazy loading of Lucene index files
- backport selected changes from trunk (such as related to yesterday's CVE)
- release 1.22.1
- (later on) retire 1.10.*
As to why not to branch based on 1.24.0: I'd like to avoid any confusion
about what is "newer". If we released 1.24.1 people might think this is
something to upgrade from 1.24.0 from (and that would be incorrect due
to the change related to OAK-7947).
Feedback appreciated,
Julian
Re: [PROPOSAL] Branch 1.22.0
Posted by Julian Reschke <ju...@gmx.de>.
On 29.01.2020 16:42, Marcel Reutegger wrote:
> Hi,
>
> This sounds good to me. It wasn't immediately clear to me why the branch
> would be from the 1.22.0 release instead of 1.24.0, but I think I
> understand now. One of the goals of the 1.22 branch would be to replace
> and retire the 1.10 branch, which means the releases from the 1.22 branch
> should provide a smooth upgrade path from 1.10.x releases. Hence, the
> proposed flip of the default for lazy index loading. I think it's important
> this is documented clearly.
>
> Regards
> Marcel
Yep, once we agree on the plan I'll create a Jira ticket for that.
Best regards, Julian
Re: [PROPOSAL] Branch 1.22.0
Posted by Marcel Reutegger <mr...@adobe.com.INVALID>.
Hi,
This sounds good to me. It wasn't immediately clear to me why the branch
would be from the 1.22.0 release instead of 1.24.0, but I think I
understand now. One of the goals of the 1.22 branch would be to replace
and retire the 1.10 branch, which means the releases from the 1.22 branch
should provide a smooth upgrade path from 1.10.x releases. Hence, the
proposed flip of the default for lazy index loading. I think it's important
this is documented clearly.
Regards
Marcel
On 29.01.20, 15:03, "Julian Reschke" <ju...@gmx.de> wrote:
> When we introduced the new release/branching strategy last March, it was
> clear that we might have to create branches once incompatible changes
> happen.
>
> Now is the time. (Well, soon).
>
> <https://issues.apache.org/jira/browse/OAK-7358> will make incompatible
> changes (so that we can compile & run on Java 14). I therefore propose
> to create a branch, from which we can continue to cut releases that are
> fully compatible with 1.22.0.
>
> The good news is that we have confirmed that 1.22.* can be used as
> drop-in replacement for 1.10.*, thus at the same time (or close to it)
> we could retire 1.10.
>
> The only issue we found was due to slightly changed system behaviour
> when lazy loading of Lucene index files is in effect. I would therefore
> propose to disable that feature in the first release from that branch
> (see <https://issues.apache.org/jira/browse/OAK-7947>, there's a system
> property for this, we would just have to flip the default value).
>
> (And yes, this proposal is equivalent to just replay *any* change made
> in trunk to 1.10.*)
>
> The concrete steps would be:
>
> - create the branch based on the tag 1.22.0 - flip the default for lazy
> loading of Lucene index files - backport selected changes from trunk
> (such as related to yesterday's CVE) - release 1.22.1 - (later on)
> retire 1.10.*
>
> As to why not to branch based on 1.24.0: I'd like to avoid any confusion
> about what is "newer". If we released 1.24.1 people might think this is
> something to upgrade from 1.24.0 from (and that would be incorrect due
> to the change related to OAK-7947).
Re: [PROPOSAL] Branch 1.22.0
Posted by Julian Reschke <ju...@gmx.de>.
On 31.01.2020 13:29, Julian Reschke wrote:
> On 29.01.2020 15:03, Julian Reschke wrote:
>> ...
>> The concrete steps would be:
>>
>> - create the branch based on the tag 1.22.0
>> - flip the default for lazy loading of Lucene index files
>> - backport selected changes from trunk (such as related to yesterday's
>> CVE)
>> - release 1.22.1
>> - (later on) retire 1.10.*
>> ...
>
> I just created the branch
> (<https://svn.apache.org/repos/asf/jackrabbit/oak/branches/1.22/>), and
> will now start backporting changes from trunk.
>
> I also opened <https://issues.apache.org/jira/browse/OAK-8888> to track
> the defaults change to the lazy loading of Lucene index files.
>
> Best regards, Julian
The changes made between 1.22.0 and 1.24.0 which make sense in this
branch have been backported.
Nitin has taken care of OAK-8888. (thanks)
With that, I think we can plan a release. I'll work on the release notes
on Wednesday, and plan to cut the release at the end of the week.
Best regards, Julian
Re: [PROPOSAL] Branch 1.22.0
Posted by Julian Reschke <ju...@gmx.de>.
On 29.01.2020 15:03, Julian Reschke wrote:
> ...
> The concrete steps would be:
>
> - create the branch based on the tag 1.22.0
> - flip the default for lazy loading of Lucene index files
> - backport selected changes from trunk (such as related to yesterday's CVE)
> - release 1.22.1
> - (later on) retire 1.10.*
> ...
I just created the branch
(<https://svn.apache.org/repos/asf/jackrabbit/oak/branches/1.22/>), and
will now start backporting changes from trunk.
I also opened <https://issues.apache.org/jira/browse/OAK-8888> to track
the defaults change to the lazy loading of Lucene index files.
Best regards, Julian
[PROPOSAL] Branch 1.22.0
Posted by Julian Reschke <ju...@gmx.de>.
Hello team.
When we introduced the new release/branching strategy last March, it was
clear that we might have to create branches once incompatible changes
happen.
Now is the time. (Well, soon).
<https://issues.apache.org/jira/browse/OAK-7358> will make incompatible
changes (so that we can compile & run on Java 14). I therefore propose
to create a branch, from which we can continue to cut releases that are
fully compatible with 1.22.0.
The good news is that we have confirmed that 1.22.* can be used as
drop-in replacement for 1.10.*, thus at the same time (or close to it)
we could retire 1.10.
The only issue we found was due to slightly changed system behaviour
when lazy loading of Lucene index files is in effect. I would therefore
propose to disable that feature in the first release from that branch
(see <https://issues.apache.org/jira/browse/OAK-7947>, there's a system
property for this, we would just have to flip the default value).
(And yes, this proposal is equivalent to just replay *any* change made
in trunk to 1.10.*)
The concrete steps would be:
- create the branch based on the tag 1.22.0
- flip the default for lazy loading of Lucene index files
- backport selected changes from trunk (such as related to yesterday's CVE)
- release 1.22.1
- (later on) retire 1.10.*
As to why not to branch based on 1.24.0: I'd like to avoid any confusion
about what is "newer". If we released 1.24.1 people might think this is
something to upgrade from 1.24.0 from (and that would be incorrect due
to the change related to OAK-7947).
Feedback appreciated,
Julian
Re: [SUMMARY] Branching and release
Posted by Francesco Mari <ma...@gmail.com>.
On Thu, 28 Mar 2019 at 14:13, Davide Giannella <da...@apache.org> wrote:
> I saw we still have versions like 1.10. Do we want to overall go through
> a bit of sanitisation in Jira?
>
I think we should get rid of pseudo-versions like 1.10. I always found them
confusing. Why not using only concrete versions we are going to release?
Re: [SUMMARY] Branching and release
Posted by Davide Giannella <da...@apache.org>.
On 28/03/2019 10:17, Marcel Reutegger wrote:
> There is still a fix version 1.11.0 in JIRA and resolved issues get that fix
> version in addition to 1.12. If there are no objections, I'd like to remove
> the 1.11.0 fix version from all resolved issues and the project as well.
> I don't see a reason why we should keep it since we do not intend to
> create such a release.
Done! Thanks for spotting.
All 1.11.0 are now 1.12.0 and 1.11.0 has gone.
I saw we still have versions like 1.10. Do we want to overall go through
a bit of sanitisation in Jira?
Cheers
Davide
Re: [SUMMARY] Branching and release
Posted by Marcel Reutegger <mr...@adobe.com.INVALID>.
Hi,
+1, this all sounds good to me.
On 27.03.19, 15:20, "Davide Giannella" <da...@apache.org> wrote:
> - Any new official release will be always even: 1.12.0, 1.14.0, 1.16.0,
> ..., 1.124.0
There is still a fix version 1.11.0 in JIRA and resolved issues get that fix
version in addition to 1.12. If there are no objections, I'd like to remove
the 1.11.0 fix version from all resolved issues and the project as well.
I don't see a reason why we should keep it since we do not intend to
create such a release.
Regards
Marcel