This project is read-only.

Should 1.4 really be 2.0?

Topics: Announcements
Feb 16, 2012 at 8:15 PM

Orchard is trying to adhere to the semantic versioning convention (major.minor.patch, where major means breaking changes are allowed).

We would have liked Orchard 2.0 to have some really major, groundbreaking changes, and while what's currently in 1.x has some really super-extra-neat new features (I mean, how sweet are Projector and Autoroute?), it's not as major as we'd like for a 2.0. Still, we have some major breaking changes in there, to the point where we need all module authors to review and in some cases modify their code. We do have a migration path but it won't be a smooth update where everything just works right away.

This is why we want to ask you: should Orchard 1.4 really be called 2.0?

Arguments for and against are very welcome. The steering Committee will be taking the decision on this next Wednesday.

Feb 16, 2012 at 8:24 PM
Edited Feb 16, 2012 at 8:25 PM

In this particular case, I think the right decision would be to just rev to 1.4. It's one of those situations where from a product/marketing perspective, yes the 2.0 would have been beneficial, but from the developer perspective knowing that going from 1.x to 1.4 doesn't mean that I'll have to be rewriting a bunch of code because of potential breaking changes is also beneficial. 

I think of it this way: knowing the scheme being used follows semantic versioning, if someone came to me and said "hey, 1.4 is out... do you think we should upgrade?" vs "hey, 2.0 is out... do you think we should upgrade?", as a developer, I would be able to able to more quickly/easily answer the question because I could at least immediately rule out breaking API changes being a blocker to adopting the new version.

Just my 2¢.

Feb 16, 2012 at 8:27 PM

Thanks, but there *are* breaking changes, and many developers will have to adapt their code. I'm a little confused about what you mean here.

Feb 16, 2012 at 9:21 PM

It should definitely be 2.0. If it breaks, the major version changes. Don't worry about the round 2.0 number, leave that to the marketing drones.

Feb 16, 2012 at 9:42 PM

+1 for 2.0

It's groundbraking and it's possibly breaking. That's major.

Feb 16, 2012 at 10:11 PM
Edited Feb 16, 2012 at 10:13 PM

Although what's in 1.x is something big in terms of advances I agree that it isn't as major as it IMO should be for a 2.0. What I would do here if Orchard would be my own little project is increment the minor version number by more than one. I think 1.5 differs from other minor versions (that's a feeling, nothing really rational) that it indicates a mature software, almost in its full glory. So basically pushing purely algorithmic versioning aside, I would go with 1.3-1.5-2.0, unorthodox it might be.

On the other hand it could be a bad release habit to release so much change at once so that a jump from 1.3 (or even 1.4) would happen to 2.0 (speaking generally, now that's not the case). So a more rational approach could be to describe the set of functionality targeted for 2.0 (I think there is something like this written somewhere on the Documentation site), implement these incrementally with every release and when everything is done just hop to 2.0. And that could well be even from 1.9.

BTW if it goes for 2.0 the modules could be broken with an IStorageProvider change (like this or this) too ;-).

Feb 17, 2012 at 6:22 AM

+1 for 2.0

Feb 17, 2012 at 8:33 AM

+1 for 2.0 Because it's more clear that it could have "breaking changes".

Feb 17, 2012 at 9:28 AM
Edited Feb 17, 2012 at 9:29 AM

To me it feels more natural to move to 1.4, but if the decision has been made to adhere to semantic versioning, then the rules seem simple: it should be 2.0.

That said, Orchard is still relatively young, and many things may break in order to improve it. So, one might also say that it's still in a 1.0 BETA phase. Once Orchard contains all of the features and enhancements that the team has in mind, it gets out of BETA and into RC.

However, since it's already at version 1.4 I guess it's going to be confusing to go back into 1.0 Beta.
Perhaps it's an idea to stick to versioning as it is currently done (so call it 1.4), and once the team starts implementing features that are considered to be part of 2.0, start using the BETA and RC tags, in order to prevent having to keep jumping major version numbers when it again contains breaking changes. I believe the ASP.NET MVC team does this as well.

On the other hand, the higher the version number, the more easy it is to sell Orchard implementation to my customers (a higher version feels more major).

I'd go with 1.4, and revise the version numbering when we get to 2.0, which will contain really groundbreaking new stuff.



Feb 17, 2012 at 10:55 AM

+1 for 1.4 - I share sfmskywalker's thoughts.

Feb 17, 2012 at 11:40 AM
Edited Feb 17, 2012 at 11:43 AM

Edit: I'm not sure if this was clear - what follows is my support for sticking with 1.4:

Personally, I think "2.0" should give the following signal: "This is a mature, stable and performant product which, out of the box, is capable of delivering or exceeding all the features you'd expect from any major CMS."

Where I think 1.4 is right now is that in many cases it exceeds the featureset of other CMSs, but there are still known areas that need addressing before the above statement can be truly made with confidence. The "Features for 1.5" thread covers pretty much everything that would bring us to what I imagine as 2.0 - and not even nearly everything from that thread is necessary, I think there are about 5 major features and a few minor ones there that are really important. I also think that performance, reliability, stability, and extensibility could all get a bit more love for particular scenarios ... some absolutely amazing work has been done in these areas lately, but my feeling is that 2.0 could be rock solid.

The roadmap I'm imagining is that the 1.5 release will add a few more of the "big" features the community wants and/or developers are planning; and that will finally be followed by 2.0 which will fit any final pieces into the puzzle and have given time for the 1.3/1.4/1.5 features to get fully matured and as bugfree as is ever possible!

So I guess what I'm suggesting is that 2.0 could actually be much less about groundbreaking new features, and more about making a statement that the project as a whole has reached a really major milestone, and that all the prior "feature arcs" are completed. After all, each release so far has had its share of major changes - think Shape Tracing, or Rules - and whilst Autoroute and Projections are awesome kind of because they tie so many other things together, I think it's very representative of Orchard's evolution and philosophy that even just a minor version brings something completely new to the table.

Feb 17, 2012 at 11:56 AM

Ok Randomepete convinced me after his explanation that 1.4 would be better indeed.

Feb 18, 2012 at 11:47 AM
Edited Feb 18, 2012 at 11:48 AM

Yes the randompete explanation sits the most reasonable in my eyes, +1 for 1.4

Feb 19, 2012 at 3:48 AM

My Vote is for 2.0. The Orchard CMS is one of the best engineered CMS's of modern times and considering other frameworks which are less mature have higher rev #'s. I think calling it 2.0 would send a strong signal to the developer community..

Feb 19, 2012 at 6:58 AM

My votes is for 2.0, it sounds like there is enough there to move a major version number.

Feb 19, 2012 at 7:17 AM

The problem with 2.0 is that everyone thinks Orchard is already very mature in all it's features and it could be a disappointment that some feature don't exist yet out of the box and it's possible they start writing bad reviews about it because of that. I fact it's feature set is already amazing high, i know but it could be a problem. I would say use 1.4. The other problem is that when we use direct 2.0 is that there could be a lot incompatible modules and that also could result in bad reviews by the ones that are new to Ochard.

Feb 19, 2012 at 7:23 AM

But there *will* be a lot of incompatible module no matter what number we stick on it.

Feb 19, 2012 at 7:32 AM

yes and that's why i don't think it's sensible to use 2.0 instead of 1.4. with 2.0 we get a lot more new users, i'm sure about that. I think the risk is to big with the incompatible modules.

Feb 19, 2012 at 8:43 AM

So you seem to be basically arguing against semantic versioning in general, and want us to have *less* new users than we could?

Feb 19, 2012 at 8:59 AM

o no i love to see new people start using and develop Orchard. I think it's the best architected CMS there is at the moment for ASP.Net. no doubt about that. But i'm afraid we could lose some new people because they get disappointed by the incompatible modules. But i'm not sure about that. What's you opinion about this discussion (Bertandleroy)? A well in the end it's just a number, right :) 

Feb 19, 2012 at 9:00 AM

I'm on the fence. I have a small preference for 2.0, but I want to hear what people have to say.

Feb 19, 2012 at 9:07 AM

ok understandable. I would say go for 2.0 when there's a good check if modules are compatible with the new version.So you can't break your orchard instance by installing a old module which is incompatible.

The current found problem about that: I have a installed v1.3 instance and i saw that there was a update for the Cache module. I installed it but it had dependencies with the New 1.4 (Alias module) release so my local site crashed.

Feb 19, 2012 at 11:25 PM

@Znowman I understand your point. The incompatibilities between custom modules (or just their bad design/bugs etc.) which bomb the whole instance are the thing that could possibly discourage lots of potential users from using Orchard, no matter how cool would the framework be. Orchard itself is a victim here, unfortunately.

In my opinion we should stick to 1.x versioning for now, until we make the framework itself more bulletproof to the erroneous modules. But I agree with Bertrand that we won't make it 100% proof ever (as it happens with any other software). At least we can try to pinpoint the most common scenarios and handle those.

Naming it 2.0 would mean that it's a basically new product, free (at least to significant degree) from the common issues it's predecessor had. But UX regarding dealing with custom modules (and all the possible problems in between) hasn't changed much. It's perfectly ok for me and other devs, but think about users who do not know/care about how the modules they install work, whether there are some incompatibilities etc. From their perspective, it should just work. And if it doesn't, framework should handle that nicely. We're not there yet.

Feb 20, 2012 at 4:34 PM

I would improve the non-technical user experience before making it 2.0. I think with some UI changes and some GUI tools for editing this product could have the best usability of any CMS I've used.

Improving the documentation would help first time implemented a lot too (I made two pull requests this weekend). I spent more time than I wanted Googling and experimenting to fill holes in my understanding from reading the documentation over the past couple weeks.

Feb 20, 2012 at 10:11 PM
smithd98 wrote:

I would improve the non-technical user experience before making it 2.0. I think with some UI changes and some GUI tools for editing this product could have the best usability of any CMS I've used.

Improving the documentation would help first time implemented a lot too (I made two pull requests this weekend). I spent more time than I wanted Googling and experimenting to fill holes in my understanding from reading the documentation over the past couple weeks.

+1 for that - exactly what I had in mind.

Feb 21, 2012 at 1:57 AM

Thanks for the doc pushes by the way, I just accepted the pull requests.

Feb 22, 2012 at 9:41 PM

We voted on this today and the decision was to use 1.4. Thanks to everyone who chimed in.

Feb 24, 2012 at 9:37 AM