You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Stefan Seifert <ss...@pro-vision.de> on 2017/02/28 16:45:29 UTC
[fsresource] version numbers | fork
the filesystem resource provider exists for a long time and is very useful. until version 1.1.4 it supported only the "old" Sling Resource Provider SPI.
in version 1.2.0 it was switched to the new Resource Provider SPI. this was an backwards incompatible change because one of the osgi config properties had to be renamed (provider.roots -> provider.root).
i'm currently working on some major improvements (SLING-6440, SLING-6537), and i want to support both the old and the new Resource Provider SPI, so basically I want to fork it and maintain two separate versions.
looking back it was not a good idea to release the switch to the new SPI in the 1.x version range because it breaks semantic versioning due to the config property change (i had missed this change as well at that time).
my proposal is:
- once the implementation is ready release the fsresource provider fork supporting the old Resource Provider SPI as 1.3.0, and further releases as 1.x
- release the new version for the new Resource Provider SPI as 2.0.0
the drawback of this proposal is that we have a few older releases in the 1.x line (1.2.0 and 1.2.2) that are not in line with semantic versioning, but this would be fixed in 1.3.0 and upwards.
any objections?
stefan
Re: [fsresource] version numbers | fork
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Mar 1, 2017 at 2:54 PM, Stefan Seifert <ss...@pro-vision.de> wrote:
> ...the plan was to use a svn branch for the "old SPI": [1] ...
>
> ...we are doing this already like this for the parallel maintenance of osgi-mock and sling-mock 1.x / 2.x. [2] and it works quite well...
Ok, I wasn't aware of that - works for me, thanks for clarifying!
-Bertrand
RE: [fsresource] version numbers | fork
Posted by Stefan Seifert <ss...@pro-vision.de>.
>How do you intend to manage both branches of the fork? svn branches?
>Maybe creating a new "legacy" Maven module for one of them would be
>clearer.
the plan was to use a svn branch for the "old SPI": [1]
release would then be done both on the trunk (2.x) and this branch (1.x) versions.
we are doing this already like this for the parallel maintenance of osgi-mock and sling-mock 1.x / 2.x. [2] and it works quite well.
stefan
[1] https://svn.apache.org/repos/asf/sling/branches/fsresource-1.1.x
[2] https://svn.apache.org/repos/asf/sling/branches/testing/mocks/
Re: [fsresource] version numbers | fork
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Feb 28, 2017 at 5:45 PM, Stefan Seifert <ss...@pro-vision.de> wrote:
> ...the drawback of this proposal is that we have a few older releases in the 1.x
> line (1.2.0 and 1.2.2) that are not in line with semantic versioning, but this would be
> fixed in 1.3.0 and upwards...
I think that's reasonable.
The alternative would be to use 3.0.0 for the "legacy branch" to more
clearly indicate the fork, but that's not necessarily better.
How do you intend to manage both branches of the fork? svn branches?
Maybe creating a new "legacy" Maven module for one of them would be
clearer.
-Bertrand