Currently our practice (not very reliably followed) is to maintain one branch and tag at release. A release tar ball should also be published. This policy was developed back when backporting livecd-tools to older releases pretty much wasn't done.
We seem to be moving toward pushing back new releases into older Fedoras. If we have some significant user impact changes (of the need to change workflow kind), we may end wanting to track separate branches. Also even adding feature changes mixed with bug fixes may cause us to run afoul of the updates policy. So we should at least be thinking about what we would want to do for branching, even if we don't need this right now.
Given the lack of manpower we have, and that our new features don't tend to break users' workflows, I would be inclined to just have one branch for now and tag when making a release tar ball. If we get push back on doing updates in Fedora, then I think we will want to start using branches for bug fixes. (The alternative is to use patch files in the packages, but that gets messy and is more work.)
On Sat, Nov 13, 2010 at 08:58:51AM -0600, Bruno Wolff III wrote:
Currently our practice (not very reliably followed) is to maintain one branch and tag at release. A release tar ball should also be published. This policy was developed back when backporting livecd-tools to older releases pretty much wasn't done.
We seem to be moving toward pushing back new releases into older Fedoras. If we have some significant user impact changes (of the need to change workflow kind), we may end wanting to track separate branches. Also even adding feature changes mixed with bug fixes may cause us to run afoul of the updates policy. So we should at least be thinking about what we would want to do for branching, even if we don't need this right now.
Given the lack of manpower we have, and that our new features don't tend to break users' workflows, I would be inclined to just have one branch for now and tag when making a release tar ball. If we get push back on doing updates in Fedora, then I think we will want to start using branches for bug fixes. (The alternative is to use patch files in the packages, but that gets messy and is more work.)
I was hoping we could use master for all the current branches, but I'm already running into problems with that. My proxy patch and the dracut patch should only be on master since they would break previous releases.
Now is probably a good time to start using branches. We could also take the additional step of matching the release version to the fedora release like anaconda does.
Moving forward livecd is going to be more tightly coupled with the anaconda and fedora releases so a branch for each fedora release would be preferable to carrying patches. Anaconda is working on integrating installing to an .img file so most of python-imgcreate will hopefully be provided by anaconda.
I've added a 'release' target to the makefile to make it easier to remember to tag the release and update the tar on fedorahosted.org
I'll go ahead and create branches for f13 and f14 (I don't think f12 is worth any effort since it's EOL in 2 weeks IIRC). master will track rawhide, branches will be named fXX-branch
On Mon, Nov 15, 2010 at 14:49:03 -0800, "Brian C. Lane" bcl@redhat.com wrote:
Now is probably a good time to start using branches. We could also take the additional step of matching the release version to the fedora release like anaconda does.
This seems reasonable, since upstream is really tied to Fedora releases.
I'll go ahead and create branches for f13 and f14 (I don't think f12 is worth any effort since it's EOL in 2 weeks IIRC). master will track rawhide, branches will be named fXX-branch
As long as f12's version is lower there shouldn't be a problem. Unless you did something odd, that should be the case.
livecd@lists.fedoraproject.org