this is not clear to me. will we not be able to push updates to Kolab 16 anymore, after the release of Kolab 17?

This resolve the need to support N past versions in parallel (16, 17, 18, ...) and keep focus on the current release. A useful way to think about this is that 17.0 supersedes a 16.2 release; so instead of doing a 16.2, we move directly on to 17.0, and that becomes the upgrade step from 16.1.

But not everyone will upgrade to Kolab 17.0 on release day. Some people might want to wait a bit until they hear enough reports of success, until they upgrade. Therefore it should still be possible to maintain Kolab 16 for some while.
I understand that we cannot support older releases for a long time. Perhaps define a limited time of parallel support for Kolab 16 and Kolab 17 (perhaps 6 or 9 months?).

If we want to get Kolab into distributions, we need to have longer support anyway, at least for the upstream packages.

IMO you can't really call it 17.0, 17.1 and 17.2 if they're all delivered from the same Kolab:17 repo. I would like to compare it with Debian Releases. Version 7.0 becomes stable, 7.1, 7.2, etc are smaller updates. When Debian 8.0 comes out Debian 7.x becomes oldstable and gets community support and/or max security fixes. At some point in the future when 9.0 comes out and become stable, 7.x gets moved to the archive and doesn't receive any updates while 8.x becomes oldstable

This the community has at least a change to uptime withing 1 or 2 years while enterprise customers have their 5 year business plan.

In one of the roadmap blogposts there was something written that X.0 will be the new release while the first iteration X.1 will become the base of the new enterprise distribution. I personally would wait until the dot.1 release comes out before I would upgrade from the previous to the most recent release. But that's likely because of debian packaging bugs in the past which needed to be reviewed first most of the time.

not everyone will upgrade to Kolab 17.0 on release day.

That is absolutely fine, and expected. But this is true no matter how the version numbers would be handled / labeled. We missed the target with 16.1 by half a year; 17.1 will be out in a more timely fashion, allowing people to upgrade with reasonable rapidity.

Therefore it should still be possible to maintain Kolab 16 for some while.

With security updates, sure. With feature enhancements, non-critical bug fixes, etc. it is generally not feasible to do a good job of that with the resources that are available in the community as a whole. Such ongoing support can only be done properly with significant commitment and support, and that is the point of subscription: it supports the efforts required to take on maintenance of prior releases as the product moves forward.

If people want to sit on Kolab 16 for an extended period of time, they should pick up a subscription to support that. It coincidentally helps forward development as well, but for the subscriber there is the immediate benefit of knowing they don't have to make a choice between upgrading or falling increasingly out of date.

And by "extended period of time" I don't mean just mean 5 years, or even 3. 2 years is already quite a commitment if we are also to keep putting out 2 releases per year which also contain necessary forward development and improvements.

IMO you can't really call it 17.0, 17.1 and 17.2 if they're all delivered from the same Kolab:17 repo

We already do the functional equivalent that, so it is evident that we can :)

This the community has at least a change to uptime withing 1 or 2 years while enterprise customers have their 5 year business plan.

Firstly: enterprise customers are part of the community too. They give back significantly more than the vast majority of other users in the community, and not only monetarily but also in terms of testing, end-user feedback, requirements creation, event attendance and support, etc. They are on equal footing in my eyes with users of Kolab who participate in development, documentation, translation, etc. So let's give them their due and admit they are part of the community, and try to move away from this "enterprise vs community" language which is simply not accurate.

Simply put: have users of Kolab, some of whom pay for support and SLAs, and others who don't. They are all part of our community.

It is obviously up to each user how to participate with Kolab: as a user that has no contact with the Kolab community projects, as a user that participates in the creative flow, and those who choose to also support Kolab financially either because they realize the intrinsic value in doing so or because they want the quid-pro-quo that Kolab Systems offers in return.

Those who use Kolab without participation have all the source code and access to stable releases at least once per year (if we ignore the .0 releases). There is no reasonable expectation for it to be packaged to their personal convenience beyond that.

What I do think would be reasonable is to recognize community participation as a form of currency and offer those who participate in the creative processes that make Kolab in a meaningful way (people in this discussion fall into that category, easily :), and work out a sensible way to provide access to long term support packaging repos for those peoples' personal Kolab usage. Something to discuss in future, and hopefully sooner rather than later?

This entire discussion should probably be moved somewhere more useful rather than this differential though :)