Discuss making master branch tip of current development

[j-griffith]

I'm not sure if this has already been discussed, and there might be a really good reason for the repo layout that's in place... but I'll raise the discussion anyway.

Going to this repo and puling master ends up with unexpected consequences of checking out the latest master of the current release; makes sense once a new comer figures that out :)

I was wondering what folks thought about changing the repo layout slightly, use version branches and tags for released versions of the plugin and using master as latest/greatest cutting edge version of the plugin? We would then cut a branch and tag when we're ready for a release, and then also maintain the branch we released on and tag a new release from that with updates when needed.

Process would go something like:

• Create csi-v0.3 branch
• Set up CI items to run on csi-v0.3 branch
• Set up CI to run on master branch (assuming we rebase it to match current v1.0 branch)
• Rebase master to current csi-v1.0 branch
• Determine strategy for releases
• Determine policy for backports to our "release branches"

Thoughts?

[ShyamsundarR]

Agree.

Also related to #255 and actions being taken there. (specifically this comment)

I would further like to add that we should not update the images in quay for every PR that gets merged, rather make selected tag based release (as suggested) and update the images in quay on these tags.

Also, the images in quay should start using the 'z' in x.y.z that is being maintained.

This enables users to stay at a x.y.z version till they decide to move ahead, and this is enabled by us not updating the same tag for every PR that we merge.

[j-griffith]

@ShyamsundarR thanks, I hadn't seen that one.

[ShyamsundarR]

Agree with the laid out list of items to run down to close on the task.

I was tempted to add a "List pending tasks to release v1.0" to the task queue above, but that maybe beyond current scope of what we intend to achieve in this discussion (or not, hence dropping it here for consideration anyway).

[j-griffith]

@ShyamsundarR That's a good point, I think it falls in the "middle" somewhere; I'd be curious what @Madhu-1 and @humblec think. Personally I'd probably favor having a new issue created for it, even if we reference it here at some point.

[Madhu-1]

@j-griffith Agreed, we can have a separate issue for it.

[humblec]

@j-griffith Completely agree on your thought. IOW, we already have some discussions going on this. As a first step, we have cut v0.3 branch from current master. Setting up CI is a common pending item for this repo and we had some discussions around it and hopefully we will be making some progress on this.

The only pending item is, how to make/rebase master to v1.0 branch. @rootfs any thoughts on next course of action on this?

[j-griffith]

@humblec Great, looks like that branch was just cut in the last 10 hours or so? As far as the rebase, it's ugly and brute force, but what about just removing the current master and dropping in v1.0, commit; push?

We'll still have git history in the other two branches, the initial update might look ugly but it should work.

[humblec]

@humblec Great, looks like that branch was just cut in the last 10 hours or so?
Yeah! You got him :)

As far as the rebase, it's ugly and brute force, but what about just removing the current master and dropping in v1.0, commit; push?

Yeah, thats a brute force approach and I am bit worried about the folks who already cloned and working on (may be with a fork) thinking master is on v0.3 branch. but in other way, we dont have any choice!

We'll still have git history in the other two branches, the initial update might look ugly but it should work.

Agreed..

[j-griffith]

@humblec Yeah, there's an "ugly" cut over no matter what here; I don't know of another way to address it other than to get through the pain sooner rather than later (it only gets worse if we wait longer). I guess the other option is to advertise that the branches will be changing, leave master idle for a while, changes are only allowed in V0.3 and V1.0.

The idea being that we could lock down master for a while to make sure everybody is aware of what's happening and then switch over. This does sort of mess with the idea of "released" vs "under development" but we're early enough and not doing releases really anyway so maybe that's ok. Thoughts? @rootfs may have a better solution too of course.

[humblec]

I guess the other option is to advertise that the branches will be changing, leave master idle for a while, changes are only allowed in V0.3 and V1.0.

IMO, above is a good idea. One drawback here is, people may think we are not progressing on this repo. But , the default branch of this repo is csi-v1.0 , so thats kind of taken care.
@rootfs please share your thoughts and lets fix our path :)

[ktdreyer]

I think it makes a lot of sense to have "master" be the main branch, just like other projects (ceph, rook, etc).

[Madhu-1]

@j-griffith can we close this one?