sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Munteanu <>
Subject Re: [DISCUSS] Best way of deprecating modules
Date Tue, 02 Jul 2019 11:47:06 GMT
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 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,, 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:



> -Georg
> [1] 
> [2] 

View raw message