0.4: branched

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
Post Reply
User avatar
Z-Man
God & Project Admin
Posts: 11589
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

0.4: branched

Post by Z-Man »

Trunk is in a pretty good state right now, I'm going to branch off for 0.4 in the next couple of days, depending on boredom level. Here's the plan, or at least the bits relevant to you:

The 0.4 branches will still be synced with SVN, that is required to do the merging properly. Merging is supposed to go like this:

From 0.2.8 to 0.4, merges are going to be happening in SVN. We can't get them off 0.2.8 any other way, and changes to 0.2.8 are usually fixes we also want in 0.4 without hassle.
From 0.4 to trunk, merges should happen in BZR. We should exploit its history preserving merge feature where we can.
Yeah, that does give changes to 0.2.8 made in bzr the awkward lifecycle 0.2.8 bzr -> 0.2.8 svn -> 0.4 svn -> 0.4 bzr -> trunk bzr -> trunk svn, but we'll just have to deal with that. I'll be the one doing most of it; I can monitor the bzr-svn sync process, so I'm the one least likely to get annoyed waiting for it to finish (or get started).

As soon as the branching is complete (wait for my post, it's going to be a bit complicated to set up the syncing, don't just take the appearance of new branches as signal), you should migrate bugfixing activities you'd previously have done on trunk to 0.4. If you're implementing a feature and are not sure whether it belongs into 0.4, develop it from 0.4 and merge the finished result into trunk; that way it can sit there for a bit getting tested and we can pull it out cleanly back into 0.4 if it's deemed worthy. Look up 'daggy fixes' if you're unsure how that's supposed to work. If you accidentally directly implement bugfixes on trunk, don't sweat it, it's OK if we just keep 0.4 and trunk in perfect sync for the first two weeks or so. And yeah, all the features you were planning to add to 0.4 can still go there.

I won't declare 0.4 the new source of alpha snapshots right away; the first step will be to make the experimental snapshots auto-merge changes from 0.4. The latest time for moving 0.4 to alpha status would be when crazy new stuff gets added to the trunk.

Desired timeframe: 3-6 months to the first beta build, 3 more for 0.4.0.
User avatar
Z-Man
God & Project Admin
Posts: 11589
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.4: preparing to branch

Post by Z-Man »

Wee, that was surprisingly painless. The only trouble was that I forgot a 'svn switch' and accidentally did the first merge from 0.2.8 to trunk, not 0.4. Consider us branched.
New bzr URIs:
Main source: lp:~armagetronad-dev/armagetronad/0.4-armagetronad-work or simply lp:armagetronad/0.4
Build helper: lp:~armagetronad-dev/armagetronad/0.4-build-work
Winlibs: lp:~armagetronad-dev/armagetronad/0.4-winlibs-work
Multibuild helper (ok, I'm the only one using that): lp:~armagetronad-dev/armagetronad/0.4-build_eclipse-work

New svn URI:
https://armagetronad.svn.sourceforge.ne ... anches/0.4

Right now, the bzr branches for trunk and 0.4 are still perfectly synced, I've been using 'bzr merge --pull' to get changes from 0.4 to trunk, and I'll continue to do so as long as possible. That is until new things are added to trunk only.
User avatar
Z-Man
God & Project Admin
Posts: 11589
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.4: branched

Post by Z-Man »

Erp. bzr-svn has produced two superfluous revisions. I *suspect* it's because 0.4 and trunk are still in sync on the bzr side, but can't be on svn. Therefore, I suspended syncing of trunk between bzr and svn until the bzr branches are properly diverged. None of us are working on trunk svn any more, right?

Edit: this is not the place for bug reports. Make a new thread for them, please, or report them on Launchpad. It's easier to keep track of them then.
Post Reply