Over the past 12 months, COD 7.x-1.x has moved into BETA, creating a relatively stable platform to build conferences sites. Much of the difficulty before the beta has been resolved, and the last few months have been spent on making sure multi-event sites scale, that we can run a drupalcon, as well as other tech conferences on it, and that we remove as much of the hard-coded features as possible.
However, as we've been working on drupalcon, there were some critical features that warrant API or significant features changes that will not make it possible to seamlessly upgrade from COD 7.x-1.0-beta9 to 7.x-1.0-dev (or the unreleased Beta 10). After discussion with co-maintainers and stakeholders, it seems prudent that we keep the development going in a 2.x branch and sunset the Beta9 as the 1.0 branch.
Tag the 2.x branch from 5fae201df510464fd8c41ef0ff21a74c5daf4388 (may 4th) and backport some of the 2.x features back into 1.x where they don't cause feature or API conflicts. If there is an easy upgrade path, then we can port it back to 1.x.
For those using Beta 9 or 9.1 right now, you should continue on the 1.x branch. No new features, except those in 2.x, will be brought in. For now, 1.x will be released as an 'other' release, and we will keep the profile updated with newest drupal core and contrib modules.
For those using 7.x-1.x-dev right now, you should use the 2.x branch. We will reset this to Alpha1, although we are aiming for a full release soon. Upgrade paths aren't guaranteed until Beta. However, Drupalcon is using the 2.x branch (Actually HEAD), so it should conceivably be possible to follow head and keep your 2.x site updated.
If you are using Beta 9 or 9.1 and want to try to upgrade to the latest 2.x branch, your major problems will be around the sessions listing and schedule, if you made changes on your site. If you want to use the changes from drupalcon, you can just simply revert the features and you should get the updates.
If you're using a drush make file to manage your conference site, make sure to use the correct branch. And as always, test your site locally after update before pushing live. Even small module updates can cause problems if your site is doing something unique.
This is still a proposal, so please offer ideas, questions, or issues you think this proposal may cause.
Comments
Comment #1
hussainwebGreat work on deciding to move breaking changes to 2.x. I know this is a beta but since this has been in beta since quite some time, we have built our DrupalCamp site using this. I was on beta 9.1 and was worried when I read that beta10 will probably have breaking changes. I didn't want to manage security releases.
I just upgraded to beta10 today on http://drupalcampbangalore.org/ and it's working fine. I had to tweak some of my views, and panelizer displays but it was a smooth upgrade overall.
I will look forward to upgrading to 2.x for the next event. For now, we are good with 1.x as the camp is less than 20 days away.
Comment #2
ddease2 commentedGood work. I'll continue to use and support the 2.x track. I put off my latest install as there were just too many variables and questions to make me feel confident that I could deliver and support it.
I still believe this project has tremendous potential and is desperately needed in the Drupal community. Keep it up!
Comment #3
mrconnerton commentedI am not very thrilled about the proposal mostly because part of what made this a great year for COD 1.x was the renewed support in the platform from people who had lost faith in it previously. I've spoken a lot about COD at camps across the states. At those events I got a lot of people who were not to excited about COD simply from being burned before in early alphas however have since told me how great the latest betas are that they have started to build sites with.
One of the big selling points that they like is that there has been an upgrade path for quite a while now and this was finally going to be the last year that they would have to build a site from scratch. Moving to 2.x means that we have to go back to all these people and tell them to start over if they want to have the latest features and bug fixes. I think that is going to really hurt the renewed support we have gotten and might be the last straw for many.
I would like to see some examples of API and feature changes that can't be accomplished worse case with hook_update_N.
I love COD and am going to continue to put my time and effort into it, but if that effort goes into 2.x I highly doubt any of us are going to continue to maintain 1.x. There would be no reason and we would be leaving all those sites out to dry.
With all of that said if the effort for hook_update_N is really to great, then we don't have a choice. My only two modifications to the proposal would be:
Comment #4
japerryThanks for everyone's comments!
So in terms of 2.x, many people can do a clean upgrade -- but the fragile state of distributions in drupal is partially why making another branch, based off of the changes, is necessary. The things that have been found with building drupalcon, PNWDS, and linuxfest, have shown that we cannot easily do update scripts.
The best example here is anything relating to views and panels. Almost every camp has made some type of change to it. When we change views to use panes and panels, it breaks backwards compatibility with sites that did customizations. Honestly, commons has a similar issue for -every- version that introduces an update hook to a feature -- we're potentially ruining someones work.
Mrconnerton, you're right about the promise we gave to people about not breaking sites from beta to beta, and thats why I'd like to start on the 2.x branch. I realized that we pretty much already had a stable release that people are building from, and we can make small changes to those who are using the 1.x branch, while encouraging them to update to 2.x. 1.x is a commitment to that promise that we can deliver security updates while not breaking people's sites, where as 2.x is still stable, but more cutting edge, for those starting new sites or those who can run diffs between their current site and the code that changed.
I guess I see 1.x branch being 1.x-slow and 2.x being 1.x-fast. Sadly the naming convention in drupal versioning doesn't let us really articulate that well.
Lastly, in terms of having to rebuild a site -- it is the goal that you do NOT have to rebuild your site to go from 1.x to 2.x. All data structures will include upgrade paths, whereas you may have to do some tweaking to your features in order to get them to work correctly with the new site.
Interestingly, Hussianweb, I mistagged Beta10 last night and it included all of the work that is now in the 2.x branch. (hence why we really need two branches for the distribution) So if you have successfully updated, move to 2.x because your essentially on that branch already.
I have 2.0 marked as an Alpha today for basically two reasons:
1) Siren. Its the new layout hotness for a theme, and is being iterated on as I type this. Pisces will be removed from the 2.x branch, and depending on what you did with a subtheme, you may need to override more of the theme, it really depends on your own usecase.
2) Node + Panelizer based landing pages. Its become apparent that having hard-coded panels for each landing page doesn't really work for multi-event sites. You'll have different blocks for different events, and the current setup doesn't allow this. Similar to how we moved program to a basic page content type, we would want to move schedule, sessions, etc to their own landing pages that would be built by the user.
Once these two issues are resolved, we can goto beta -- which should quickly goto an RC.
Comment #5
ddease2 commentedjaperry: is there any way to check out the Siren theme?
All: is the reason for panels and panelizer to reduce the amount of custom page template theming needed? It seems to add an administrative layer to editing the site that makes for confusion. Am I alone on this one? ;-)
Comment #6
japerryddease2:
Its coming soon! I know its on DyanneNova's list to get into the 2.x branch this week. She and Bojana are working on it in her branch and I hope for public review this week.
Regarding panelizer and panels: In general, different events may have different configurations/layouts, so using panelizer allows you to create different content displays per event. The goal is partially to reduce the need for custom templates and give admins the power to easily build new events without having to create a bunch of code.
Panels provides better contexts to administrative pages than simple blocks (which have no idea of context) or views pages. While custom code could be used to create these pages, panels allows for a (hopefully) much smoother upgrade path when D8 comes out... instead of porting a bunch of custom code.
Basically, the hope is there shouldn't be much need for custom page templates. Using pre-defined layouts in your theme (or in ours, like Pisces, Siren or the new COD kickstarter) and applying them to pages should give you everything you need.
Comment #7
japerryComment #8
ddease2 commentedjaperry: thanks for the update and info. I'm definitely looking forward to seeing Siren, but that's even better to hear about COD Kickstarter. That was my next suggestion, as I'm a big fan of Commerce Kickstart. What's the present status of Kickstarter? Any idea when it will be available?
GREAT work!
Comment #9
mrconnerton commentedSo just to be clear, you are saying we can upgrade 1.x or 2.x at any time, but if we revert our features its going to kill any panels and views overrides we have, but everything else will be in update scripts? I guess one solution, at least for views is features overrides.