directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject RE: Rename master branch to trunk and create 1.0.0-RC2 branch for the upcoming release
Date Tue, 29 Dec 2015 08:20:44 GMT
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://drankye@git-wip-us.apache.org':
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: kerby@directory.apache.org
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:elecharny@gmail.com]
Sent: Monday, December 28, 2015 3:30 PM
To: kerby@directory.apache.org
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.


Mime
View raw message