[TYPO3-v4] Deprecation of t3lib_div::testInt() in TYPO3 4.6

[Andreas Wolf]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

Am 23.11.2011 11:46, schrieb Ernesto Baschny [cron IT]:
> Georg Ringer schrieb am 23.11.2011 11:35:
>>> Because there is a list of those wrapper functions a new
>>> extension is born; another extension programmers library.
>> 
>> this is just the case if an extension wants to be supprted in 2
>> major versions at the same time with the same version!
>> 
>> extension authors still can just say version 1.0 > for 4-5 and
>> use 2.0 for 4-6 and develop only the new one.
> 
> I would love to see more support for "branches" in extension 
> development, so that the same rules and regulations that we have
> for the core can also be applied with extensions.
> 
> I am pretty sure there are extension developers that *want* to
> support multiple branches at the same time (especially a branch
> that works with 4.5 LTS), but currently TER (and EM) lacks support
> of handling multiple "valid" versions of the same extension (only
> the "last one wins").
> 
> EM should load the "last one that is still supported by current
> TYPO3 version" that should win.
> 
> TER should allow to upload a new version of an older branch too.
> 
> This would avoid people having to add tons of TYPO3-core version 
> switches inside the extensions, and would allow more professional 
> extensions to pop up which have release cycles that make sense (a
> stable branch, a development branch, a backwards compatibility
> policy etc).
> 
> If we could figure out how this could be done in TER, we could
> even backport this "feature" to 4.5, as it would make perfect
> sense especially there.

+1.

The current concept of TER is quite "buggy" - maybe it would help to
have a look at e.g. PEAR to see how they handle these things.

I think it would also make sense to have something like prereleases in
TER, so you could release alpha and beta versions of extensions. A
TYPO3 installation could then say which "degree of stability" it
wants, and thus exclude these prereleases, while you could still
easily get them for your local test/dev installations.


Cheers
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREIAAYFAk7M0fkACgkQHWtXp155bP+8PwCfQcXg9Il3E3CR2HNbNRlH31FX
XvoAnicfCR14WvPFf6+v0caoLMrvd/g1
=fgRr
-----END PGP SIGNATURE-----