You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2019/07/02 11:47:06 UTC
Re: [DISCUSS] Best way of deprecating modules
Hi Georg,
On Tue, 2019-05-28 at 22:59 +0200, Georg Henzler wrote:
> Hi Robert,
>
> sorry to only get back to your comment [1] now - so I tried a couple
> of
> versions back and forth and I believe it would be best to do the
> following:
Well, I took my time to reply apparently :-)
>
> * Create a branch "maintenance" with the last version before
> deprecation
> (but as it is a branch hotfix releases could be cut from it if
> necessary)
> * Leave the repo empty with a sole README.md file and add a line
> "For
> reference or potential bugfix releases use branch maintenance"
>
> See fork [2] in my user account to illustrate how this approach
> looks
> like.
>
> The advantage is that
>
> * the README file with the obsolete text is not overseen (with the
> long
> list of folders/files from src/main, CONTRIBUTING.md, to pom.xml the
> notice in the README would get easily overlooked)
> * if necessary it's still easy to look at the code (one click) or
> even
> release from it (maven-release-plugin does not worry too much about
> branch names)
Thinking some more about it, I think the most important parts are:
- to keep the old source code available
- to make it clear that the code is deprecated
Browsing around Github I generally see deprecated projects in the same
layout as non-deprecated ones, but if you think using a 'maintenance'
branch is fine let's go with that.
I think we should document this deprecation procedure to make sure we
follow it. Could you please doucument your proposal somewhere under
[3]? I think it's safe to assume there are no objections.
Do you also have a script for applying it? Some modules that are
deprecated according to the downloads page do not reflect that in Git:
https://github.com/apache/sling-org-apache-sling-commons-threaddump
https://github.com/apache/sling-org-apache-sling-scripting-jsp-taglib-compat
https://github.com/apache/sling-org-apache-sling-hc-samples
Thanks,
Robert
[3]: https://cwiki.apache.org/confluence/display/SLING/Developing+for+Sling
>
> WDYT?
>
> -Georg
>
> [1]
> https://issues.apache.org/jira/browse/SLING-8418?focusedCommentId=16846509&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16846509
> [2]
> https://github.com/ghenzler/sling-org-apache-sling-starter-startup
Re: [DISCUSS] Best way of deprecating modules
Posted by Georg Henzler <sl...@ghenzler.de>.
P.S. I just created
https://cwiki.apache.org/confluence/display/SLING/Deprecating+Sling+Modules
On 2019-07-03 07:22, Georg Henzler wrote:
> Hi Robert,
>
> thanks for your feedback (even if it took some time apparently :) ) -
> will document in [1] as discussed.
>
> -Georg
>
> [1]
> https://cwiki.apache.org/confluence/display/SLING/Developing+for+Sling
>
> On 2019-07-02 13:47, Robert Munteanu wrote:
>> Hi Georg,
>>
>> On Tue, 2019-05-28 at 22:59 +0200, Georg Henzler wrote:
>>> Hi Robert,
>>>
>>> sorry to only get back to your comment [1] now - so I tried a couple
>>> of
>>> versions back and forth and I believe it would be best to do the
>>> following:
>>
>> Well, I took my time to reply apparently :-)
>>
>>>
>>> * Create a branch "maintenance" with the last version before
>>> deprecation
>>> (but as it is a branch hotfix releases could be cut from it if
>>> necessary)
>>> * Leave the repo empty with a sole README.md file and add a line
>>> "For
>>> reference or potential bugfix releases use branch maintenance"
>>>
>>> See fork [2] in my user account to illustrate how this approach
>>> looks
>>> like.
>>>
>>> The advantage is that
>>>
>>> * the README file with the obsolete text is not overseen (with the
>>> long
>>> list of folders/files from src/main, CONTRIBUTING.md, to pom.xml the
>>> notice in the README would get easily overlooked)
>>> * if necessary it's still easy to look at the code (one click) or
>>> even
>>> release from it (maven-release-plugin does not worry too much about
>>> branch names)
>>
>> Thinking some more about it, I think the most important parts are:
>>
>> - to keep the old source code available
>> - to make it clear that the code is deprecated
>>
>> Browsing around Github I generally see deprecated projects in the same
>> layout as non-deprecated ones, but if you think using a 'maintenance'
>> branch is fine let's go with that.
>>
>> I think we should document this deprecation procedure to make sure we
>> follow it. Could you please doucument your proposal somewhere under
>> [3]? I think it's safe to assume there are no objections.
>>
>> Do you also have a script for applying it? Some modules that are
>> deprecated according to the downloads page do not reflect that in Git:
>>
>> https://github.com/apache/sling-org-apache-sling-commons-threaddump
>> https://github.com/apache/sling-org-apache-sling-scripting-jsp-taglib-compat
>> https://github.com/apache/sling-org-apache-sling-hc-samples
>>
>> Thanks,
>> Robert
>>
>>
>> [3]:
>> https://cwiki.apache.org/confluence/display/SLING/Developing+for+Sling
>>
>>>
>>> WDYT?
>>>
>>> -Georg
>>>
>>> [1]
>>> https://issues.apache.org/jira/browse/SLING-8418?focusedCommentId=16846509&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16846509
>>> [2]
>>> https://github.com/ghenzler/sling-org-apache-sling-starter-startup
Re: [DISCUSS] Best way of deprecating modules
Posted by Georg Henzler <sl...@ghenzler.de>.
Hi Robert,
thanks for your feedback (even if it took some time apparently :) ) -
will document in [1] as discussed.
-Georg
[1]
https://cwiki.apache.org/confluence/display/SLING/Developing+for+Sling
On 2019-07-02 13:47, Robert Munteanu wrote:
> Hi Georg,
>
> On Tue, 2019-05-28 at 22:59 +0200, Georg Henzler wrote:
>> Hi Robert,
>>
>> sorry to only get back to your comment [1] now - so I tried a couple
>> of
>> versions back and forth and I believe it would be best to do the
>> following:
>
> Well, I took my time to reply apparently :-)
>
>>
>> * Create a branch "maintenance" with the last version before
>> deprecation
>> (but as it is a branch hotfix releases could be cut from it if
>> necessary)
>> * Leave the repo empty with a sole README.md file and add a line
>> "For
>> reference or potential bugfix releases use branch maintenance"
>>
>> See fork [2] in my user account to illustrate how this approach
>> looks
>> like.
>>
>> The advantage is that
>>
>> * the README file with the obsolete text is not overseen (with the
>> long
>> list of folders/files from src/main, CONTRIBUTING.md, to pom.xml the
>> notice in the README would get easily overlooked)
>> * if necessary it's still easy to look at the code (one click) or
>> even
>> release from it (maven-release-plugin does not worry too much about
>> branch names)
>
> Thinking some more about it, I think the most important parts are:
>
> - to keep the old source code available
> - to make it clear that the code is deprecated
>
> Browsing around Github I generally see deprecated projects in the same
> layout as non-deprecated ones, but if you think using a 'maintenance'
> branch is fine let's go with that.
>
> I think we should document this deprecation procedure to make sure we
> follow it. Could you please doucument your proposal somewhere under
> [3]? I think it's safe to assume there are no objections.
>
> Do you also have a script for applying it? Some modules that are
> deprecated according to the downloads page do not reflect that in Git:
>
> https://github.com/apache/sling-org-apache-sling-commons-threaddump
> https://github.com/apache/sling-org-apache-sling-scripting-jsp-taglib-compat
> https://github.com/apache/sling-org-apache-sling-hc-samples
>
> Thanks,
> Robert
>
>
> [3]:
> https://cwiki.apache.org/confluence/display/SLING/Developing+for+Sling
>
>>
>> WDYT?
>>
>> -Georg
>>
>> [1]
>> https://issues.apache.org/jira/browse/SLING-8418?focusedCommentId=16846509&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16846509
>> [2]
>> https://github.com/ghenzler/sling-org-apache-sling-starter-startup