Re: One Git repo per major version
Hi Oleg On Mon, May 15, 2017 at 11:06 AM, Oleg Kalnichevski 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 >> 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
Re: One Git repo per major version
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. Oleg > Regards > Julian > > > > On Wed, May 10, 2017 at 9:44 PM, Michael Osipov > 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
Re: One Git repo per major version
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 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
One Git repo per major version
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
