On Mon, Feb 18, 2019 at 2:03 AM Mark Thomas <ma...@apache.org> wrote:
> On 18/02/2019 09:13, Rémy Maucherat wrote: > > On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov <micha...@apache.org> > wrote: > > > >> Folks, > >> > >> given that we are currently in the process of migrating to Git I'd like > >> to propose a more readible and with the branch names consistent tag > >> naming scheme. > >> > >> The given approach, for whatsoever reason, performs an uppercase and > >> replaces dots with underscores. This reduces readability, but also > >> requires people (esp. package maintainers) to perform sed(1) magic to > >> convert back and forth. > >> > >> There are bascially two approaches I'd like to discuss: > >> > >> Approch 1: It will reuse the branch name of the current major version, > >> excluding master. Thus, we will have the following prefixes: tomcat90-, > >> tomcat85-, and tomcat70-. Since JDBC Pool remains in place and if it is > >> released separately the prefix would be jdbc-pool-. The version itself > >> would remain as-is and simply appended, e.g., 8.5.40, 9.0.25, etc. > >> > >> Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit > >> would be autocompletion in Git CLI. I could simply say: "git checkout > >> tomcat85" or "git checkout tomcat85-<TAB>" and grab the specific version > >> I want. > >> > >> Approach 2: A simpler, less redundant approach would be naming the > >> branches master, 7.0.x, 8.5.x, etc. and get rid of the "tomcat" prefix > >> at all. The tags would simply be the versions as-is: 8.5.40, 9.0.25, > >> etc. The Git autocompletion will work here too. > >> > >> I personally opt for approach 2 because it is consistent, concise and > >> removes redundancy on always used prefixes. > >> > > > > I guess it's hard to argue against option 2. > > > > The main downside is that it comes late and Mark already did the work and > > lots of testing for his proposed plan. > > The current, community agreed proposal for branch naming is "master, > tc8.5 and tc7.0" > That's fine by me. > > There were strong views on the branch naming but "master, 8.5.x and > 7.0.x" would be consistent with those views. I'm not sure I see much > difference between either approach. If there is a strong preference for > one over the other - or a good reason to choose one over the other - > please make those views known in the next few days. > No good reason. Based on the OP I thought that we are comparing to a more verbose scheme like "tomcat-90-xxx" (without the standard "master" branch). I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and "7.0.x"). If tags will only use the numeric versions then this will make it easy to differentiate between branches and tags. > > The current proposal, community agreed proposal for tags is to continue > with the current naming scheme. Switching to using the version as-is > (9.0.1, 9.0.2, etc) is doable. It is just a little more work during the > migration. If the as-is naming scheme makes it easier for downstream > users then that strikes me as a good reason to change it. Are there any > objections to doing so? > Git tags are very lightweight, they are just pointers to other commits, so if it's easier, we can do the migration as-is and then write some script to generate new tags with the new naming convention, it shouldn't be too hard IMO. The old tags can remain or be removed at a later time. They hardly take any space. Best, Igal
