I am in favour of using a single repository and branches (with a clean convention). Having a repo per version IMHO sends the wrong message, namely that the new version is completely different.
Again IMHO, we should strive to improve our backwards compatibility with version 6.x (with regard to 5.x). I even believe that commonly used APIs in 5.x would be mostly backwards compatible with 4.x if the Java packages had not been renamed. Please feel free to correct me if that assumption is wrong. Regards Julian On Wed, May 10, 2017 at 9:44 PM, Michael Osipov <micha...@apache.org> wrote: > Folks, > > since there is still some disagreement on how an issue should be applied to > 4.4.x and 5.0.x, I'd like to propose the following two ideas: > > Have one repo per major version and all pain will end: > > httpcomponents-core-4 > httpcomponents-client-4 > httpcomponents-core-5 > httpcomponents-client-5 > > Maven and Tomcat have this too. > > Alternatively, we can have the following layout per httpcomponents-core and > httpcomponents-client > > / > |-- 4.4.x > | master // this is 5.x > > Issue branches: > > 4.4.x/HTTPCORE-XXX > 5.x/HTTPCORE-XXX > > Yes, this works very well with Git. > > I am in favor of the first proposal. > > Backporting from 5.x to 4.4.x is a matter of a Git remote and merge -- done. > > What do you think? > > Michael > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
