Seems reasonable to me. No reason to complicate things with extra branches for now. I do think branches could be useful in the future (e.g. freezing master after a release candidate out until the final release is done is a pain, but shouldn't be a problem until we have more developers). I'll give this a few days for any objections. If no one objects, we can delete the support branches and update our workflow to not require them and add a description about when they will be used.
- Steve On 01/26/2018 06:48 PM, Mike Beckerle wrote: > To me, the tags are there, so no point in having a branch also until there is > a > need. > > Our support policy would of course depend on who is asking and what their > problem is and the difficulty of them upgrading to a newer release. > > But first thing we would always do is see if the issue is reproducible on the > most recent release. I would only consider supporting an old release if the > user > couldn't upgrade for some reason. > > Otherwise the policy should be we will fix on the latest release's support > branch. > > That would be my suggestion anyway. > > > -------- Original message -------- > From: Steve Lawrence <[email protected]> > Date: 1/26/18 3:41 PM (GMT-05:00) > To: [email protected], Mike Beckerle <[email protected]> > Subject: Re: old support branches - that are unsupported > > I guess it comes down to what our actual support policy is. Do we > support a release for N months? Do we support the last X releases (where > maybe N is 1?). If we want to delete old support branches, and deleting > the branch signifies we don't support that version anymore, we need a > policy for determining when we don't support a version. > > Or if the problem is just that the word "support" implies we are willing > to provide support for that branch, maybe we just need a new name that > doesn't come with that implication. In general, I haven't seen projects > delete these kinds of branches, so I lean towards this option (though, > we might want to come up with a support policy regardless). Not sure of > a good name, maybe "bugfix/", "branch/", or "devel/"? Open to suggestions. > > - Steve > > On 01/26/2018 12:03 PM, Mike Beckerle wrote: >> Can we get rid of all the support/v0.10 and similar branches prior to >> support/v1.0.0 >> >> >> There is nothing on any of these branches, and we won't do any support on >> them. >> >> (Based on that we should eliminate support/v1.0.0 and support/v1.1.0 as >> well.) >> >> >> but when I pull down the menu for choosing a branch on >> >> https://github.com/apache/incubator-daffodil >> >> >> I see a list with many support branches on it. Which suggests they are there >> and in use, but they are not. >> >> >> The equivalent tags are there, so a support branch could always be created. >> I just don't like having the suggestion that these are supported around. >> >> >
