Probably would behoove us to come up with a life cycle policy of our versions.
I agree with that. We should be committed to back porting for a certain amount of time and then dropping to security patches only and then officially mark EOL. The biggest issue is that requires a strict release schedule; something we don’t necessarily keep to right now
Maybe, for now, if we EOL 4.2.2 and a couple of us made ourselves available to those folks upgrading to v5.0.0 so they know the have some immediate support to help with hurdles they may face, more would take the leap to 5.0.0.
I would volunteer for this.
Definitely going to need @brady.miller, @sunsetsystems, and @MatthewVita’s opinion on this.
My initial thought is either Long Term Support (LTS) at maybe 3 years and then Short Term Support (STS) of maybe 1 year?
We’ve never made commitments like that before, as the project is managed by unpaid volunteers. If you promise “long term support” then who’s on the hook for providing it?
Just food for thought.
2 Likes
I think we were hoping you would Rod. 
Don’t other long term open source projects offer some type of paid support option? Perhaps a donation per ticket.
Haven’t decided yet whether this will cause migraines or stomach ulcers. maybe both
This sounds good to me, but I’m thinking that it will be a decent maintenance burden 
Also, and this won’t be a surprise, but I’m not a fan of scheduled releases. I think releases should be pushed when it makes sense (could be twice every few months or twice in a year, depending on the features and security fixes).
1 Like