Re: how many stable branches to have

[Denis Ovsienko <denis () ovsienko info>]

---- On Wed, 03 Jun 2015 19:12:03 +0100 Francois-Xavier Le Bail<devel.fx.lebail () orange fr> wrote ---- 
> On 26/05/2015 15:33, Michal Sekletar wrote: 
> > On 05/26/2015 11:46 AM, Francois-Xavier Le Bail wrote: 
> > > I propose this: 
> > > We could give an "End of Life" date for each release branches. 
> > > This mean that after this date, the tcpdump group would not update any 
> > > more the branch. 
> >
> > Having clearly defined EoL is a good idea. However I think that some 
> > releases should be picked and supported for longer periods of time. 
>  
> In the previous examples, I had given EoL dates allowing to have a  
> lifetime of support about two years. 
>  
> If it is not enough, a version, every two years approximately, could  
> have a superior lifetime, by example four years. 
> The first one of theses long-term versions could be the 1.7/4.7 ones. 
>  
> What do you think about it? 

To keep it working long-term it would help not to promise more commitment upfront than necessary. The terms above are 
more or less OK for a Linux distribution that has many users with many slow migration processes on one hand and the 
money/resources those users give back on the other. In such a situation it makes sense to engage, for instance, 20-50 
engineers per each stable branch and let the show run.

In the scope of tcpdump/libpcap it would be fair to spell a community contract of sorts that would state a baseline 
level like this:

1. The latest stable branch is always supported.
2. From time to time the developers find it right to start the next stable branch, which supersedes the old one after, 
for instance, 2 months or 2 releases.
3. Anybody who demands free support for an unsupported old stable branch (often to resell it for a price as "their" 
support, let me note) is welcome to spend their own time on the problem and to contribute the solution.

This would be within the typical expectations from an Open Source software project and the developers would still be 
free to walk an extra mile when/if they want.

-- 
    Denis Ovsienko

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers