Monkey release cycle

[arpieParticipant]

Mark, You may have seen in this thread http://monkeycoder.co.nz/forums/topic/mx2cc-crash-during-linkage/ that @abakobo is looking for a cleaner way to integrate docsCommunity commits back into the blitz-research repo.

I was wondering if you have a formal(ish) procedure for release cycles? Looking at the monkey2 repo, it looks like you used tags for a while, then abandoned them, and you have some rc branches in there, too. Does the v1.1.11rc1 branch correspond exactly to the version 1.1.11 binaries? Will you do something similar for v1.1.12?

I’d like to suggest that after every release you make, we create an identical branch on the docsCommunity repo, then shortly before you release a new version (perhaps when you create a rc branch? You will have to let us know when this is!) we can rebase any docs changes and send you a pull request for a nice clean merge into the new rc (this should avoid all the merge commits showing up twice in the git history).

Could that work for you?

[abakoboParticipant]

There must be a way to reset the fork without loosing the issues…?

EDIT: just saw your rebase, looks neat! Isn’t that enough for a clean pull request?
REEDIT: just saw Mark’s message and everything seems to be all right (and even better with a rebase)

[Mark SiblyKeymaster]

Yes, the ‘v1.1.xyrc’ branches are the ‘release’ versions, and I plan to create a new one for every release in future.

Just making pull requests for docs mods has worked fine to date IMO and I don’t want to make it more complicated than that right now.

[arpieParticipant]

@mark, I totally understand where you’re coming from but I promise a rebase will actually make it simpler.  The docs repo was running slowly out of sync with your main repo… not a major catastrophe but getting worse with each merge.

All I really want know is how you currently manage the timing of the pull requests.  If you give us a heads-up that a release is imminent we can rebase the docs on the latest develop branch just before sending you a pull request.  You won’t notice any difference but the commit history will be cleaner and the docs repo will stay in sync.

[arpieParticipant]

@abakobo Yes, a rebase is exactly what is needed for a clean pull request, and it will also keep the docs repo in sync with the main repo.  The downside is that anybody editing the files in the docs repo will have to pull a new branch after each rebase.  This is why I think it is important to limit the rebases to only be done once for each monkey release.

PS: Did you see my posts and questions here : http://monkeycoder.co.nz/forums/topic/integrated-docs-github-community-organisation/page/3/

[Mark SiblyKeymaster]

Well, I don’t know what a rebase is and have no desire to find out right now, but I’m vaguely planning a release for next week – but this is subject to not finding any problems in a ton of new stuff I’ve added before then, and also my tendancy to add things at the last minute.

I don’t really consider these ‘releases’ to be terribly significant anyway – they are really just snapshots of progress that I put together to do something nice for patreon supporters. Actual monkey2 development is an ongoing process so rebasing could easily occur at any time, couldn’t it?

[arpieParticipant]

Well, that makes it easy – there are currently no changes in the docs repo for you to pull in!

Don’t worry, rebasing occasionally will make absolutely no noticable difference to what you are currently doing.  It is simply to tidy up the docs repo.  You can totally absolutely completely trust me to make it work.  Besides, you have no idea who I am, no idea whether I actually know what I’m talking about or whether I am going to break a system that you are currently quite happy with.  And I have no relevant credentials to put your mind at ease.  What could possibly go wrong!?

Yes, you are right that rebasing can happen at any time but it’s nice to feel like I have a reason to justify otherwise arbitrary timing.

I’m already looking forward to the ‘ton of new stuff’…

[Mark SiblyKeymaster]

I’m already looking forward to the ‘ton of new stuff’…

Alas, much of it is internal. But the Scene saving/loading stuff is coming along really well, you can now open ‘.mojo3d’ scene files in ted2go!

[Author]

Posts