[Typo3-dev] TYPO3 version 4.0.0?

[Kasper Skårhøj]

Hi Daniel.

> > Please understand that I'm not suggestion to inflate the version numbers
> > beyond recognition. I just think we are too "humble" currently (and
> > traditionally!)
> 
> It is quite funny to have that coming from the development side of things.
> Normally the evolution of version numbers is merely a technical matter and
> marketing is trying to inflate these.

Actually I am kind of suggesting just that; Increasing versions based on
technical changes.
The problem to this date is that TYPO3 has been locked into beta and rc
versions for all of its daylight hours almost and that should soon end.
I know this is mostly my fault. I'll try to change.

>  
> > The future could look like this:
> > 
> > 4.0.0   
> > - Is the release we currently call 3.6.0, soon to come
> 
> Since this really is a marketing question, what exactly are the top five
> features that you think justify this step in the eyes of customers?

We could go through the changelog and try to reflect over the last 15
month. Currently I can't remember it all.

Some points (in no particular order)
- RTE API
- Improved translation API
- More documentation on the core
- FlexForms
- UTF-8 / improved charset handling
- DBAL foundation
- XHTML compliance
- Accessibility
- Fully Documented code
- Cleaned-up sources
- css_styled_content complete

Some comments: 
- Many of these things are "under-the-hood" and that is what TYPO3 Core
changes will/should always be now; The main idea is as you know that the
functionality you can *feel on your body* is in the extensions.
- Take RTE API. Took 2-3 days. Can go into the new-feature list.
- Take XHTML compliance and clean-up of the backend. Has taken maybe 50
days+. No one cares.
- Take Accessibility. Took this day to fix + little more. Can go on the
feature-list, its a buzzword.
- Take documentational efforts. Takes MANY days. No one calls this a
feature.
- Take TemplaVoila. Many people think that *this* must be the new thing
in version 3.6.0. But TemplaVoila is... an extension! It *cannot* be on
the feature list!
- Take Mount Points: I spend 5-7 days last week on fixing what I first
thought was a trivial bug. I was compelled to extend the support when I
realized how much needed to be changed if no further bug-reports were to
come in about Mount Points. I totally forgot mentioning Mount POints in
the list above - but maybe it should have a "Support for Mount Point
heavily enhanced" entry?

And finally there are spend many many days on small things. These days
I'm fighting my mail-folder of "small bugs and features" and even though
they are put there because I though they were small, many of them takes
an hour or half a day to fix/make. But will it be reason enough to make
a new version jump of some kind? Again: Everyone likes bug-fixes but no
one thinks they are new features.

So: Even DBAL foundation, taking me three weeks or so, turns out to be a
very small percentage of 15 month - but shouldn't we market it based on
its value? 
As a programmer I'm automatically thinking "Ahh, it's just a few weeks,
that's no big deal" and "Bugs? That takes months all together!". If we
should follow my worldview the feature list looks like:

Big features:
- Core is cleaned up
- Code is commented.
Smaller features:
- DBAL foundations has been implemented
- Charset support (UTF-8) [minor]


Even I can see that this doesn't make sense and I don't even think it is
that *horrible* to inverse the list even though what took the longest
time to implement was the things that are considered "small features".
Lets go with:

Big features:
- DBAL foundations has been implemented
- Charset support (UTF-8) [minor]
- .....
Smaller features:
- Core is cleaned up
- Code is commented.
- .....



> > 4.1.0 or 4.5.0 (depending on what feels more right at the time)
> > - When versioning has been implemented.
> 
> I don't get it. Somehow it seems like you are suggesting no rules at all?
> The point is, either we have development goals, then we should have a
> milestone for 4.1.0, 4.2.0, 4.3.0, 4.4.0 ... Each.
>  
> > 4.6.0
> > - When LDAP is added
> 
> Why would that not be 4.2.0? Whats so special about this.


Just examples. 
I just intended to say that we jump the version number as we feel we can
justify from a balance between work and features added. In any case we
can always discuss on this list first. I have no "pets" in this game,
except I want us to be more in tune with reality.


> 
> > 5.0.0
> > - When some great, yet unknown feature arrives or we see reason to make
> > the jump (can also be triggered by time alone).
> 
> Well, we can of course have jumps when big improvements have been made, but
> i agree with Masi to rather divide the development strands have some things
> scheduled for, let's say, version 5 and have the regular development going
> on alongside on a fast paced but normally incrementing versioned strand.
> 
> I suspect there are several people who would love to hop on the version 5
> train (e.g. For going PHP5 entirely) and just as many who are quite right
> with staying with the main strand and improving on short term goals. It
> would be a waste of creativity to not offer this possibility.

I think I don't understand your point.

> 
> BUT all of this requires a general development roadmap! I am all for it, but
> so far this was more or less out the question.

For me it still is out of the question. Make a roadmap for me and you
emprison my programming soul. I'm not against goals generally though.


>  
> > I think this makes sense.
> > - We will send a more clear signal about the development of TYPO3 which
> > really *IS* ongoing and has been for years!
> 
> It might help, but I doubt version numbers alone are so very powerful a
> communication signal. I think it also requires clear communication of the
> achievements. In traditional software development this is easy, because the
> management decides what to do and repares the product communication
> accordingly. In our case, we have the todolist and the changelog and a knack
> for surprises, which makes it very hard to communicate the novelties in
> full.

I don't get this either.

We just increment version numbers when we *have implemented* stuff and
see that a certain jump is justified. This seems like no problem for me,
but if you want to predict/define what any given future version contains
it is of course (due to the spontaneous nature of development).

When that is said, I actually DO have a more clear roadmap for what I do
next than I have ever had. However I'm not going to publish that to
anyone publicly since that would just hold me accountable for it - which
has a very negative impact on my stress-factor.


> In other words: spectacular version numbers alone, will not be pushing TYPO3
> very much further. It will also need to be accompanied with a development
> process that provides information in a way that has nooks and crannies for
> communicating what the new stuff has to offer. You will have to make that
> effort, i am afraid, since you are head of Development :-)

This I didn't understand either.

Do you think it is a big effort to justify version jumps? I think that
will be very easy since the jumps are based on exactly that: What
happend since last time.

> 
> AND it will need features that are really sensational in terms of satisfying
> wide spread important needs.

This I didn't understand either.


> Let's try to go one step back and look at what we want to achieve:
> 1. with version numbers as a form of communicating progress
> 2. with development
> 
> The discussion about development goals should come first, because this is
> where value for the customers is actually created. When we have settled on
> some agenda, we can think of how to get there. When we know that and have
> all of this settled, we can think of how to label it with version numbers.
> 

I don't want to think forward. 
I want to look at what has happend since 3.5.0, then I realize that with
version 3.6.0 now it means that with this pace we are at 3.11.0 in 2010.
Then I say "Lets increment a little more than this" and suggest that the
jumps like 3.5 -> 3.6 are made in the first digit instead. This brings
us to 4.0.0 instead of 3.6.0. And from that moment we will just
increment with greater jumps (basically moving the digit to increment).

For the future we cannot predict anything. I would even predict that if
you put up a development roadmap putting features onto version numbers
it will not be followed in real life. Features come when they come and
you will just have to constantly modify your roadmap order to reality.
If that helps you, fine. But the version numbers are just not defined by
it but rather by what actually happend.

Take DBAL as an example. Lets say that version 5.0.0 of TYPO3 was
supposed to include DBAL and version 4.0.0 was defined by having
versioning. Now, suddently we do have DBAL in version 3.6.0! So; will
you jump to version 5 without implementing versioning? Will you insist
that versioning MUST be done right here and now because otherwise we do
not follow the order of the roadmap? Or will you just say "Well, DBAL
seems to be enough to jump to 4.0.0. Lets put versioning on for 5.0.0".
I think that latter case is just fine and what we will have in reality.

- kasper