[TYPO3-english] TYPO3 6.0 at the corner? How is it possible

[Roberto Presedo]

2012/3/6 Jigal van Hemert <jigal at xs4all.nl>:
> Hi,
>

Hi,

>
> On 6-3-2012 0:57, Roberto Presedo wrote:
>>
>> reduced to a simple commercial item… But, what I try to explain is :
>> customer doesn't "need" to know which numbered version it is… It can
>> be TYPO3 "Whatever" … Behind this codename, we can use TYPO3 v6.0.0
>> without fear of "loosing" people… Here, the real challenge would be to
>> agree on a theme of codename (pets, danish villages, historical
>> figures, …) :)
>
>
> That's something that can always be added. It's more a marketing thing (not
> saying that it is not important). I personally prefer to have "TYPO3" as the
> umbrella name and add new products under that name (like "TYPO3 [some new
> name] 1.0".

Yes its a marketing thing. But if we pay attention to the majority of
the initial post's comments, and the messages of this topic, all this
debate is about marketing.. it's about how non-TYPO3 people will react
if TYPO3 5.0 is bypassed… And this is when "codenames" are useful ...

> This is a bit similar to what was done with Apache in the past. It started
> with the web server Apache and later other products were added to the Apache
> name (Apache Solr, Apache Tomcat, etc.).
> But this is more part of the issue what the [some new name] will be called.
> I'm sure there will be much more debate about that in the future :-)

For me this is true if we talk about projects like FLOW3, which are
not CMS… But  [some new name] is a CMS like TYPO3. It's like the
Apache Fondation had a new server software project that is better than
the Apache server. It's weird and the Group must support two different
CMS, within one community...

> The version number is also needed for technical reasons. Extensions can
> state that they are compatible with a certain range of TYPO3 versions.
>
> To see which version is the latest and which versions are supported we have
> a version matrix [1]. That is not going to change, so it will still be
> pretty easy to see what is the latest (stable) version.
>

I 100% agree. version number is required, but only for technical
reasons and must be separated from the marketing speeches.

>
>> Then about having a Phoenix v1.0 project (hereinafter called [some new
>> name]) I am a bit worried about the impact that its TYPO3's
>> separation can have when we'll have to move from TYPO3 to [some new
>> name]. Like Xavier says in his post "So, while it never was really
>> official, it became clear that the 5th point of the Berlin Manifesto
>> (ed : "Migration of content from TYPO3 v4 to TYPO3 v5 will be easily
>> possible") would not be met." And that's the main problem.. As part of
>> a web agency which main activity is building websites based on TYPO3,
>> we'll face a problem when we'll have to sell the "migration" from
>> TYPO3 to Phoenix… As this is not going to be an easy and smooth
>> operation, customers will be tempted to ask themselves : "Well, do I
>> move to Phoenix, or do I take a look to the others solutions of the
>> market… Because after all, this means to start everything from
>> scratch."
>
>
> At first v5 was thought of "just" a technical rewrite of the core where most
> things like content and extensions would stay more or less the same or they
> would need limited changes.
>
> On the other hand there is an obvious need for migrating content. Although
> it might not come with the core of [some new name] I'm sure that there will
> be people who will start an effort in providing migration tools.

IMO, migrations tools for core data must be supplied by either TYPO3
or [some new name] core teams. We can even think about creating a task
force dedicated to this challenge. But TYPO3 users have to be able to
make the move easily.

>
> The same will very likely happen for [some new name]. Version 1.0 will not
> have all the features everybody wants to have, but I'm sure that some smart
> person will make a migration package/extension. As other packages/extensions
> for news, guestbooks, calendars, etc. will be created these might hook into
> such a migration tool and provide means to convert old TYPO3 structures into
> data for [some new name].

You're right, this is the way migration should go. Extensions authors
should provide migration tools for their own extensions, as TYPO3 core
team definitely cannot provide such tools. But the core data, pages,
contents, configs, … must be migrate easily using tools provided by
core team.

>
> At first you won't migrate existing websites to [some new name]. It will be
> used to create new websites or complete relaunches from any other system
> (including TYPO3) where only specific data is converted.
> Once [some new name] is becoming feature complete and enough packages are
> available to have similar functionality as the old website, it will become
> easier to migrate. There will still be a lot of manual labour left; think of
> templating, user rights management.
>
> [1] http://typo3.org/download/packages/
>
>
> --
> Kind regards / met vriendelijke groet,

Cheers

>
> Jigal van Hemert.
> _______________________________________________
> TYPO3-english mailing list
> TYPO3-english at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english