Let's just rename master to trunk and leave other thoughts for future consideration as we don't get much inputs.
While I'm doing the rename, it failed due to lacking the permission. Would anybody help with this? Thanks. $ git push asf :master trunk Username for 'https://git-wip-us.apache.org': drankye Password for 'https://[email protected]': Total 0 (delta 0), reused 0 (delta 0) remote: Rewinding refs/heads/master is forbidden. remote: To https://git-wip-us.apache.org/repos/asf/directory-kerby.git ! [remote rejected] master (pre-receive hook declined) ! [remote rejected] trunk -> trunk (pre-receive hook declined) error: failed to push some refs to 'https://git-wip-us.apache.org/repos/asf/directory-kerby.git' Regards, Kai -----Original Message----- From: Zheng, Kai Sent: Monday, December 28, 2015 4:12 PM To: [email protected] Subject: RE: Rename master branch to trunk and create 1.0.0-RC2 branch for the upcoming release Hi Emmanuel, I probably understand the release process. But my question is, does the release have to happen upon on trunk (or master) branch? If not, I would still suggest we create and prepare a separate branch based on the current trunk (or master) for the release (with desired version as you insisted upon). And as to what version it would use for the named trunk (or master), I thought the release process won't care since it's separated out. Some of codes would be good to remain in trunk because we're still working on it while doing the release. It does be a valid option to use other branch for the codes, but as you may notice we're used to developing on the trunk (or master) and don't want to maintain some other branches (sure for new big features we use feature branch like pkinit-support branch), that's why I would propose a slight different approach. Essentially I thought we don't have much difference in our ways. A good side effect of the new way would be to have a separate branch for the release before and after it's done. I regard this as important for new comers and developers' sake. If you'd like to check some popular projects, you may likely find their past branches by simply 'git branch -a' command. I don't have much preference regarding the name scheme, and your suggestion sounds good to me. What I would think is, release upon a branch separately instead of directly using the trunk (or master) branch. Another rational for this would be, if it's appropriate to consider that, in future we may need to perform multiple releases (major or minor) at the same time if we can go that far. More thoughts and inputs would be very welcome. Thanks! Regards, Kai -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Monday, December 28, 2015 3:30 PM To: [email protected] Subject: Re: Rename master branch to trunk and create 1.0.0-RC2 branch for the upcoming release 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=ta >>> g;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.
