Le 28/12/15 07:56, Zheng, Kai a écrit : >>> +1 to that. > Thanks. > >>> Keep it to 1.0.0-RC2-SNAPSHOT. this is what is going to be released. >>> Don't. It's done automatically when we cut the release. > Well, don't, which surely can be an option as we used to so far. But in > someone's view, it doesn't make much sense to use the upcoming release > version for the trunk branch. I thought trunk branch can point to a somewhat > much future version as often seen in other projects. A practical question > would be, since trunk branch is exactly the branch we're going to release, > then where to put the codes that's not appropriate for the release yet? In > my proposed approach, the trunk branch and upcoming release branch are > decoupled as many projects do.
You can create as many branch as needed. The idea is that the pom.xml should only reflect what you are going to release at some point. If your branch is going to die at some point (typical of what you do wehen conducting an experimentation), then the version in your pom is irrelevant, because it will *never* become a release. Otherwise, the branch being intended to be merged back into the master branch (or the trunk, all in all, it's just a name), thn better keep the version in Pom identical. What is important here is what you want to release, and the pom.xml file keep a track of this. The branch name it self is quite irrelevant, because the maven release proecess *will* create the branch associated with what is in the pom.xml. So name your branches whatever you like in git, that's the way to go, but be sure you don't change the pom version unless it's necessary. Here, what you are suggesting (naming a branch 2.0.0) might not be a good idea if you are going to merge it into a 1.0 release : it's quite puzzling, actually. Better call the (git) branch KERBY-WITh-<feature> where <feature> is what you don't want to inject in 1.0 right away. Of course, if you are already thinking about cutting a 2.0 soon, then you *may* want to create a branch for that. At this point, I strongly suggest a discussion about the naming scheme (and at Sirectpry, we have already chososen the wrong scheme, so be free to pick a better one ;-). I would suggest a stricly incremental scheme, 'à la' chrome, or now Firefox : purely incremental versions with bug fixes (1.0, 2.0, 3.0... with 1.0.1 for a bug fix, but no minor. 1.1 would simply make things complicated). For ApacheDS, we wanted to bring a feeling of stability between majors, so we are just at 2.0 and we are using milestones to convey the message that there may be some features changes between milestones. In your case, it might be better to move at a faster version pace. > >>> of cpurse we have one : >>> https://git1-us-west.apache.org/repos/asf?p=directory-kerby.git;a=tag;h=4bea5b4979eab53e090bf051a25d1fb017512c55 > Glad we can still track it. I don't see it when run 'git branch -a'. It's > hard for users and developers to find it out. It's part of the maven release process. > >>> The release process will take charge of taht automatically. There is >>> nothing you need to do > I mean, there are some codes that are not mature for the upcoming release, > and I need to remove it out of the branch we're going to release upon. again, branch the immature code. Youc an merge it back later if needed. Give it a name in git as you please, but don't change the pom.xml version if possible.
