Recently we discussed about protocol versions end of life. This is important to have a such software development contract, because it permits to do some code cleanups after an expiration time, especially on legacy parts which are not needed and permits to continue evolution in the protocol without making code spaghettis with carbonara.

We have defined we will maintain protocol versions for two years. When releasing the next version of minetest we will increase our protocol to v24. This means minetest 0.4.11 will be the older supported version

This has two impacts:

* If you have a older client version you will not be able connect to 0.4.16 servers anymore.* If you have a older server, 0.4.16 clients will not be able to connect anymore.

I'm OK with this. Thanks for this announcement, because announcements like these are important and appreciated.But I'm only OK with it because it does not affect me, I can quickly grab the most recent version of Minetest. xDBut I still think 2 years is very fair.

Are there any download sites or software distributors (read: GNU/Linux package managers) which still ship version 0.4.10 or older? Because making sure that stone old versions don't stick around is important IMO.If there really are such places left, I think some people need a kick in the butt. ;-)

Package managers should be at least upgrading to 0.4.11 which is not a great deal for them. A game is not a standard package it cannot be stucked to a version for 5 years (hello Debian). Or at least the newest version should be in backports

two years is a good concensus to maintain code, minetest team evolves and some code parts needs refreshing, and are for somes, blocked by compatibility over all minetest life. 2 years is sufficient. Can you imagine these days playing a game non updated since 2 years just for compat ?

to complete, since 3-4 years, many developers are moving to a more agile development, and that means use application contracts, it's contracts defining the protocols to interoperate, and add a End Of Life date. This was added by the microservice model for high availability infrastructures.

If I properly understand conversation stream, MT step to majority update, it is good news.But:

nrz wrote:* If you have a older client version you will not be able connect to 0.4.16 servers anymore.* If you have a older server, 0.4.16 clients will not be able to connect anymore.

That product behavior allowed while MT is beta, after release it point at serious system problem (in engineer terminology)

I am a noob.still yet. Not so noob ) [vml] WIP and a little proof for fun PlantedTorch )))MT Strike 78a36b468554d101e0be3b0d1f587a555f396452 Great! Somebody have found it ) "My english isn't well" I know. I'm sorry )

Nyarg wrote:That product behavior allowed while MT is beta, after release it point at serious system problem (in engineer terminology)

If MT had some sort of release branches where you could backport compatibility to older versions: yes. Since MT does not have that it's kind of rolling release and thus backwards compatibility is only a nice-to-have feature that is subject to change.

Sorry i wasn't clear, but yes, i talked about 0.4.11, not 0.4.15. The contract is to maintain older protocol versions for 2 years. At this moment there is no recycling needed for map or lua calls, but if there should we should have a similar contract (for example if we change compression algorithm)

The only server I'm aware of that runs a very very outdated version of MT is Redcrabs server. It's a pity that Redcrab doesn't have time and can't update :-( Other than that, most servers ought to have no problems with getting a recent version.