1.3.6 ->1.4.0

[phaidon]

@Guite @cmfcmf @craigh @rgasch @drak

I would like to see 1.3.6 as 1.4.0. There are so many new features that I think it should be not just a 3. point release.

More about my thoughts here: http://community.zikula.org/module-Forum-viewtopic-topic-59566-start-0.htm#pid266302

[Guite]

We discussed this during the Camp, too. Imho 1.3.6 should become 1.4.0 and 1.4.0 should become 2.0.0. Not only this fits better into our versioning scheme, also we can prepare marketing much more effectively.

[craigh]

+1

[craigh]

since 1.3.6 breaks API compatibility (all modules using Gedmo extensions break, e.g. Tag). A x.x.X release breaks all the rules of http://semver.org. In fact, according to those rules 1.3.6 should be a major release :scream: - 2.0.0. But I would settle for 1.4.0. :grinning:

[cmfcmf]

+1 for 1.4.0: To show how much work was done in between it.

[rgasch]

+1 for 1.4.0

On Thu, Jul 18, 2013 at 7:02 PM, cmfcmf notifications@github.com wrote:

+1 for 1.4.0: To show how much work was done in between it.

— Reply to this email directly or view it on GitHubhttps://github.com/zikula/core/issues/876#issuecomment-21198377 .

[craigh]

I hope @drak will contribute his own response, but I image he would want everyone to review this thread:

http://community.zikula.org/module-Forum-viewtopic-topic-59366.htm

short recap: much discussion (some heated) and in the end drak agreed to write a Forward Compatibility Layer to bridge 1.3.6 > 1.4.0 module types. This was done and because (at that time) this eliminated all BC breaks, drak argued for the 1.3.6 naming.

since that time however, it has been discovered that indeed there will be some (somewhat minor to some) BC breaks - e.g. any module using Gedmo Extensions (possibly only Tag). This issue, in addition to the lengthy release cycle and the introduction of the new module structure leads me to agree that it should be named 1.4.0

IMO, then what was 1.4.0 must be renamed to 2.0.0. I think this is appropriate and could be valuable in marketing as well.

[Portugao]

+1

[espaan]

I would also like it to be 1.4.0. This makes it also for module developers a lot easier to say if you're 1.4.0 native or just compatible and so on.

It will also give some marketing sound to the new version. We're doing something new and exciting instead of just a minor bug fix release. There is now a forward compatible layer to really good new technology. We should be proud of that and call it 1.4.0

[ghost]

The 1.3 branch is going to be released as 1.3.6. I have explained why ad nauseam and spend months writing forward compatibility exactly because it addressed everyone's concerns. The reason is if we release it as 1.4.0 then we will create a split in the module eco-system just as happened before where module developer do not want to migrate their code and remain on the old way.

The forward compat layer means modules can be refactored and work in 1.3.x and will work easily in 1.4 with very few changes. The fact is, developers WILL NOT convert their modules to 1.4 any time soon. the forward compatibility layer means we can submit PRs to modernize modules now, and mod devs have no reason not to accept the contribution.

I am absolutely not going to throw away the opportunity created by writing all the forward compatibility layer and thus prevent the module ecosystem from moving forward.

Whatever the next generation is called I'm less fussed by, but the 1.3 branch will be released as 1.3.6.

Please read the discussions pointed out by @craigh

[rallek]

Why not asking the module developers? There are only very few module developers remaining. Most of them voted here already.

I do not understand the arguments of @drak. If we are renaming 1.3.6 to 1.4.0 it is the same than in the past: introducing a new layer and keeping the legacy layer available means a new second level version.

To stay with 1.3.6 would be a big failure!

To fear that the modules stay with 1.3.5 is nonsens. Only some has been migrated to 1.3.x. Most are remaining with 1.2.x today. Where is the risk to move into the new and better symphony world with a new second level version?

Only Drak is not voting for a 1.4.0. All other important core and module developers are voting for 1.4.0. We should respect this voting! Gesendet mit BlackBerry® Webmail

-----Original Message----- From: Drak notifications@github.com Date: Thu, 18 Jul 2013 13:58:55 To: zikula/corecore@noreply.github.com Reply-To: zikula/core reply@reply.github.com Subject: Re: [core] 1.3.6 ->1.4.0 (#876)

The 1.3 branch is going to be released as 1.3.6. I have explained why ad nauseam and spend months writing forward compatibility exactly because it addressed everyone's concerns. The reason is if we release it as 1.4.0 then we will create a split in the module eco-system just as happened before where module developer do not want to migrate their code and remain on the old way.

The forward compat layer means modules can be refactored and work in 1.3.x and will work easily in 1.4 with very few changes. The fact is, developers WILL NOT convert their modules to 1.4 any time soon. the forward compatibility layer means we can submit PRs to modernize modules now, and mod devs have no reason not to accept the contribution.

I am absolutely not going to throw away the opportunity created by writing all the forward compatibility layer and thus prevent the module ecosystem from moving forward.

Whatever the next generation is called I'm less fussed by, but the 1.3 branch will be released as 1.3.6.

Please read the discussions pointed out by @craigh

---

Reply to this email directly or view it on GitHub: https://github.com/zikula/core/issues/876#issuecomment-21214460

[phaidon]

The fact is, developers WILL NOT convert their modules to 1.4 any time soon. the forward compatibility layer means we can submit PRs to modernize modules now, and mod devs have no reason not to accept the contribution

In fact we have a problem with the module refactoring. But this problem is not because of version numbers. The problem is the permanent refactoring. And if we continuing like that soon we wont have any module developers and without no module developers they also wont be new core developers.

So how can we make the refactoring faster? Very easy: Giving the developers the feeling that there wont be a refactoring some months later again.

How can we reach that? By having a clear and trustable roadmap in which refactoring and api changing are big things and not a permanent state. This is the reason because I suggested to create now a (module-api) stable 1.x branch with forward compatibility to the 2.x api.

The BC is there. This is a fact. So lets be honest: call it 1.4.0 or 2.0.0, make it as small as possible and find solution to have a better development way in future which is not producing BC all the time.

[Portugao]

@phaidon +1

[phaidon]

Let me add some explenations why this topic is important for me. In fact the version number is for me not the biggest issue (even it is important), but at the moment I see a lot of different module version. Here a overview of modules version I expect in the future:

(1. Modules working with 1.2.x)

2. Modules working with 1.3.1-1.3.5 (1.2. modules)
3. Modules working with 1.3.6-1.3.x (BC break by jquery) (1.3. modules)
4. Modules working with >= 1.3.6 (1.3. modules)
5. Modules working with >= 1.3.6 (2.0. modules)
6. Modules working with >= 1.4.x (BC break by jquery) (2.0. modules)
7. Modules working with >= 1.4.x (BC break by jquery) (1.3. modules)
8. Modules working with >= 2.0.0 (I am pretty sure we change some things in api until we release 2.0.0, because it will be a long time period until then and we will have new experience by migrating modules)

Of course some of this things are not changeable anymore but I have worries that we are improving the process.

Especially now when have this great forward compatibility layer (thanks a lot drak) we should think about that.

My vision would still be to have maximum 2 modules version. One for 1.3.x-1.x and one for 1.3.6-2.x. IMHO we could let the second even a little bit more time unstable to test if it is good like that.

I think by that we could motivate the modules developers more and maybe even find some new core developers.

[ghost]

I've no problem with having a roadmap, none at all.

I would like to share some thoughts. Please read and digest them.

1) Module developers write code for popular core versions - we know this already. Devs don't want to have to write a module for two separate versions. So, they stay with the platform that is most supported. This happened with 1.2->1.3 remember. In fact, some devs have only just updated to 1.3 because they wanted to support only 1.2. Their only incentive to convert modules to 1.3 was the fact that now, the majority of people are on 1.3.

So the final stop is Symfony based moduled, based on the whole Symfony Bundle concept but converted to be modules that are installable etc (Bundles are not like our modules in Symfony).

Next, there is resistance for users to upgrade from one major release to the next. We saw that again with 1.2 and 1.3 - and there is even less incentive if module developers only support 1.2 modules. See. So, it's like this, in order to get the new module standard adoptable by both users and module developers there needs to be two things. a) and install base that can run those modules, and b) modules to run.

The idea of 1.3.6 (which was widely accepted and encouraged by the way is that users have the incentive to upgrade to 1.3.6 because there are hundreds of bug fixes. In doing so, their installations will automatically BE ABLE TO run the new modules, but DO NOT HAVE TO. This means users can use either module type. More freedom to the user. That is the point of Forward Compatibility - it's better than Backward Compatibility since you can move forward without breaking things and not be stuck with huge technical debt.

It means that module devs can freely upgrade to the new module structure without upsetting their users and without their users having to upgrade core to a new major version (2.0 or whatever it's called).

2) 1.3.6 reduces the stepping stones and allows us to cease BC for several things in the next major version without leaving users in the lurch and without forcing users into a hole like we did before

3) There is no way to extract the bugfixes from the 1.3 branch - there are hundreds and hundreds of them. So I don't know how you can make a bug fix only release now.

Recap, if you release 1.3 branch as 1.4 firstly, you lose all the bug fixes, there is no maintenance release for 1.3.x currently, and there is no feasible way to extract those out. If you release 1.4.0 then users will stay on 1.3.x for a long time and not need to upgrade, so there is zero incentive for module developers to refactor code AND MORE IMPORTANTLY, THERE IS NOT INCENTIVE FOR THEM TO ACCEPT PRs TO UPGRADE MODULES TO 1.4 standards because they will then be burdened with maintaining two version. History shows module developers do not want to do this, nor really have the git-magic skills to do so.

SUMMARY

At this time, there is simply no hurry or urgency because the current code needs to go though quite a bit of QA anyhow. There is nothing to release immanently and so no real panic should be necessary.

[rallek]

and if there is no 1.3.6 anymore? Rename the current 1.3.6 to 1.4.0 It is just a number!

With this argument please start reading the postings again. It makes no sence the 1.3.6 to make bugfix only. There have been to many commits during the last months. But the renaming is an important message. That is the point!

By the way: The number of live sites driven by 1.3.5 is very small. The most used version is still 1.2.x. We can see this in the requests in our german forum.

And a roadmap would be very wellcome! Not a timing but the content which should come into which version.

[ghost]

The most used version is absolutely not 1.2.x

[rgasch]

I believe you, but the fact is that we have no hard data to back this up.

Maybe it would be a good idea to implement a "report anonymous usage statistics" option into Zikula ... this could ping our servers once a week with a quick report of the ZK version used.

That way, over time, we would get a picture of which versions are adopted to what degree. Right now we don't know. We just know what the small group of core devs are using, but that could be (but does not have to be) a realistic picture of ZK usage.

Just a thought.

Greetings R

On Fri, Jul 19, 2013 at 10:30 PM, Drak notifications@github.com wrote:

The most used version is absolutely not 1.2.x

— Reply to this email directly or view it on GitHubhttps://github.com/zikula/core/issues/876#issuecomment-21275504 .

[ghost]

Actually, we did have some polls done quite a while back. I dont seem to have them any more but they were very clear - virtually no-one on 1.1.x and just a few 1.2.x.

[rgasch]

Yes, but that only reaches the people on the forum. An automated measuring of usage statistics might be a better option.

Greetings R

On Fri, Jul 19, 2013 at 11:11 PM, Drak notifications@github.com wrote:

Actually, we did have some polls done quite a while back. I dont seem to have them any more but they were very clear - virtually no-one on 1.1.x and just a few 1.2.x.

— Reply to this email directly or view it on GitHubhttps://github.com/zikula/core/issues/876#issuecomment-21277723 .

[rallek]

Robert, this type of measuring would also not tell the trouth. Most of us do have a 1.3.x test site. Most sites with the use of clip and/or mediashare are sitting on 1.2.x. And that are really a lot of sites!

But that is not the point of the discussion. In this discussion all but Drak are voting for the renumbering. Aren't there anybody else with arguments against renumbering? I am interested in the argemunts of them as well!

[rgasch]

OK, good point, I didn't think about the test sites.

As for renumbering: I think that horse has been beaten to death, at this point I just don't care anymore. I'm just happy that progress is being made :-)

Greetings R

On Fri, Jul 19, 2013 at 11:46 PM, rallek notifications@github.com wrote:

Robert, this type of measuring would also not tell the trouth. Most of us do have a 1.3.x test site. Most sites with the use of clip and/or mediashare are sitting on 1.2.x. And that are really a lot of sites!

But that is not the point of the discussion. In this discussion all but Drak are voting for the renumbering. Aren't there anybody else with arguments against renumbering? I am interested in the argemunts of them as well!

— Reply to this email directly or view it on GitHubhttps://github.com/zikula/core/issues/876#issuecomment-21279540 .

[cmfcmf]

Robert, this type of measuring would also not tell the trouth. Most of us do have a 1.3.x test site.

OK, good point, I didn't think about the test sites.

I think it would be possible if it would only send usage statistics if

• developement mode is off
• there are at least five registered users

[rgasch]

• developement mode is off
• there are at least five registered users

I agree with the development mode thing, but the registered users thing is IMHO not valid. You could have a very popular (or at least useful) corporate site which doesn't allow user registration and thus never hits 5 users.

Greetings R

[espaan]

True

Business websites can be 1 or just a few users. And still very well visited and "money making".

But as long as we get 136/140 however it will be called in a RC state then progress can be made with updating sites to the latest (and greatest ;-)) version.

• developement mode is off
• there are at least five registered users

I agree with the development mode thing, but the registered users thing is IMHO not valid. You could have a very popular (or at least useful) corporate site which doesn't allow user registration and thus never hits 5 users.

[phaidon]

I can understand drak, that he want to see the user migrating as fast as possible, but there is reason why there are different levels in the version numbers.

A change of the last number means that the changes are small and and not very risky. Therefore the user updates in the believe the page will work after the update without problems.

But in the case of 1.3.6 this is not true. The changes are massive. Because of that there is also a big potential of problems by the update, even the release is good tested. If you dont believe me check the forum.

So the result will be, that some people will have serious problems after a minor update. This will be not good for the reputation of Zikula.

Of course a 1.3.6 release wont have very bad impacts, but I see this decision as part of imho a non optimal release strategy, which is together with the unstable module api the reason why the group of active developers is not growing. I know that this things will become better and I think the 1.4 release would a step that would help.

[ghost]

We are way way too focused on some numbers here. At this time, I would rather we get the code working. The activity recently has been great over the last month https://github.com/zikula/core/pulse/monthly

[cmfcmf]

We are way way too focused on some numbers here. At this time, I would rather we get the code working. The activity recently has been great over the last month https://github.com/zikula/core/pulse/monthly

That's true, although I won't have that much time anymore because holidays are almost over.

[phaidon]

I agree in the point that we should not to much focus on the number thing - I dont think it is the right decision but I can life with a 1.3.6 release - for me it is more about the whole thing and that is a very important discussion (see my forum post). For me it just makes sense to invest time in Zikula if I know what are the exactly development plans.

I must know how long a customer/or me can use modules which I make and when will a technology droped. The new technology are great, but I need a clear concept about their implementation and legacy support, otherwise I can not use Zikula for my business work and then I have to reduce my time for it.

[ghost]

I absolutely agree, a clear plan and communication is very very necessary because it allows people to plan. But the goals and support for 1.3 are very clear, so there is no great incompatibility issue coming for anyone on 1.3 at all. There are a few small differences, unavoidable, but mostly it's ok 99.5% compatible let's say.

[rojblake]

Given the recent change in forthcoming version number this one can now be closed.

-Mark