Hi Oleg On Mon, May 15, 2017 at 11:06 AM, Oleg Kalnichevski <ol...@apache.org> wrote: > On Mon, 2017-05-15 at 10:09 +0200, Julian Sedding wrote: >> 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. >> > > Hi Julian > > I believe this idea is off the table. > > >> 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. >> > > As far as package names are concerned some while ago we agreed to use > the same approach as Commons and use distinct packages for major > releases in order to make them co-locatable.
Thanks for this bit of information. I believe it's unfortunate, but of course it's a trade-off and both sides have valid arguments. So let's leave it at that. Regards Julian > > Oleg > > >> 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 >> > > --------------------------------------------------------------------- > 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
