[TYPO3-core] After the LTS is before the LTS

[Alexander Opitz]

Heyho,

thanks to all that there is a plan how to progress. And it realy sounds 
good.

But I think the versioning and deprecation have some points to discuss.

Versioning
==========

As I understand from the blueprint in short:

- EAR => 7.0 ... 7.y
- LTS => 7.y+1.z or 7.99.z but called TYPO3 CMS 7

Cons:
- Most OS projects use the x.90.z schema for alpha/beta/RC of the x+1 
product
- For consumers TYPO3 CMS 7 is older as 7.y from the EAR.


Proposed versioning:
====================

As many persons already mentioned, a Year.Month combination would be 
nice, so I would suggest following plan:

TYPO3 CMS 6.2
TYPO3 CMS 2014.05 CLEAN <-- Only removes deprecation, updates API Level 
to next X Version which is 7
TYPO3 CMS 2014.06 EAR <-- (Take a 2 month cycle for this example)
...
TYPO3 CMS 2015.06 EAR
TYPO3 CMS 2015.08 FREEZE <-- Last EAR for LTS
TYPO3 CMS 7 <-- Promoted Version 7, internal version 2015.10, API Level 7)
TYPO3 CMS 2015.09 CLEAN (API Level 8)

Bugfix Releases:
TYPO3 CMS 7 (2015.10.z Bugfix releases).


An extensions is installable/can be activated if:
- API Level is supported ('supportLevel' => '7,8')
- Minimum TYPO3 CMS version is installed ('cms' => '2014.08')
So an extension can be developed while a new LTS is in development and 
after the LTS, if nothing is deprecated for this extension, the API 
Level of support needs only be extended.
You can check as extension the version number if a feature should be 
existent and by API level if something was removed.

Big features can get their own test releases, before they go into 
master. They can get "TYPO3 CMS 2015.03 FEATURENAME" as version till 
merge to master and get tested by a wider audience.

Cons of this concept is the usage of 2 "version" numbers.

Deprecation
===========

Deprecated parts will be removed with every new starting EAR, but the 
concept says, you will be able to leave one LTS version out, so you have 
to consider two deletions. This will be as hard as upgrading from 4.5 to 
6.2.


Maybe we can get this API changes moved out in a compatibility 
extension, which adds the functionality back as super classes (like the 
old XClass). To get upgrades running (for one version). On the other 
side this effort may be to time consumption.


-- 
Alexander Opitz

PLUSPOL interactive GbR
Floßplatz 4
04107 Leipzig

Telefon:   (0341) 350 585 -19
Telefax:   (0341) 350 585 -40

E-Mail:    opitz at pluspol.info
Internet:  http://www.pluspol.info

Geschäftsführer:
Dipl. Medienwirt (FH) Jörg Brückner
Dipl.- Ing. (FH) Stefan Dittmar
Dipl.- Ing. (FH) Thomas Lange

USt-ID-Nr.: DE221591186

Sitz der Gesellschaft und Gerichtsstand ist Leipzig