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 <slawre...@apache.org> Date: 1/26/18 3:41 PM (GMT-05:00) To: dev@daffodil.apache.org, Mike Beckerle <mbecke...@tresys.com> 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. > >
