no 4-7-0 branch for core yet?
i am trying to checkout a 4-7-0 branch from core for a client. I want him to get all updates to this branch just by cvs up. But that branch does not exist yet AFAICT. Is there some better way to do this. Should we ask Dries and team to create one? I suppose it doesn't exist yet because we haven't opened up HEAD for features. -moshe
On 2/16/06, Moshe Weitzman <weitzman@tejasa.com> wrote:
i am trying to checkout a 4-7-0 branch from core for a client. I want him to get all updates to this branch just by cvs up. But that branch does not exist yet AFAICT. Is there some better way to do this. Should we ask Dries and team to create one? I suppose it doesn't exist yet because we haven't opened up HEAD for features.
I just tried the same thing today, and yes, this tag does not exist. I think creating one means an official release has happened, which is not the case today. Perhaps you can check out HEAD, then overwrite it with a checkout of DRUPAL-4-7-0 when it happens? Too messy ...
Hi, On Thu, 2006-02-16 at 23:14 -0500, Khalid B wrote:
On 2/16/06, Moshe Weitzman <weitzman@tejasa.com> wrote:
i am trying to checkout a 4-7-0 branch from core for a client. I want him to get all updates to this branch just by cvs up. But that branch does not exist yet AFAICT. Is there some better way to do this. Should we ask Dries and team to create one? I suppose it doesn't exist yet because we haven't opened up HEAD for features.
I just tried the same thing today, and yes, this tag does not exist.
I think creating one means an official release has happened, which is not the case today.
Perhaps you can check out HEAD, then overwrite it with a checkout of DRUPAL-4-7-0 when it happens? Too messy ...
This is what I am doing with my sites. I am checking out HEAD for the moment and as soon as 4.7 is tagged I will do a "cvs up -r DRUPAL-4-7" and start following 4.7 Gordon.
It does not seem to be a good idea at this stage to me that we even give some distant impression that HEAD is open for features. It is not. Goba Moshe Weitzman wrote:
i am trying to checkout a 4-7-0 branch from core for a client. I want him to get all updates to this branch just by cvs up. But that branch does not exist yet AFAICT. Is there some better way to do this. Should we ask Dries and team to create one? I suppose it doesn't exist yet because we haven't opened up HEAD for features.
-moshe
The tag (branch) doesn't exist yet. Creating the branch complicates matters as we have to commit each patch twice. I wanted to create the branch as soon we release a 'release candidate'. Talking of which, should we release another beta (beta 5) or should we go straight to a release candidate? On 17 Feb 2006, at 12:25, Gabor Hojtsy wrote:
It does not seem to be a good idea at this stage to me that we even give some distant impression that HEAD is open for features. It is not.
Moshe Weitzman wrote:
i am trying to checkout a 4-7-0 branch from core for a client. I want him to get all updates to this branch just by cvs up. But that branch does not exist yet AFAICT. Is there some better way to do this. Should we ask Dries and team to create one? I suppose it doesn't exist yet because we haven't opened up HEAD for features.
-- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
The tag (branch) doesn't exist yet. Creating the branch complicates matters as we have to commit each patch twice. I wanted to create the branch as soon we release a 'release candidate'. Talking of which, should we release another beta (beta 5) or should we go straight to a release candidate?
release candidate
+1 release candidate. (Crazy idea: should 4.7 be renamed 5.0? I wonder why Drupal went so fast from 1.0 -> 4.x, then languished 4.x land for some long, years for 4.2, 4.3, 4.4, 4.5, 4.6 too long) The changes are huge under the hood, and porting modules to forms API is non trivial. Would it be better to call it 5.0? (Ducks under the desk). On 2/20/06, Moshe Weitzman <weitzman@tejasa.com> wrote:
Dries Buytaert wrote:
The tag (branch) doesn't exist yet. Creating the branch complicates matters as we have to commit each patch twice. I wanted to create the branch as soon we release a 'release candidate'. Talking of which, should we release another beta (beta 5) or should we go straight to a release candidate?
release candidate
Khalid B wrote:
+1 release candidate.
(Crazy idea: should 4.7 be renamed 5.0? I wonder why Drupal went so fast from 1.0 -> 4.x, then languished 4.x land for some long, years for 4.2, 4.3, 4.4, 4.5, 4.6 too long)
The changes are huge under the hood, and porting modules to forms API is non trivial.
Would it be better to call it 5.0?
(Ducks under the desk).
As a user I am with you on this one - it look like a lot more than a point release to me. (Follows lead and ducks under desk) -- Martin Tomes echo 'martin at tomes x org x uk'\ | sed -e 's/ x /\./g' -e 's/ at /@/' Visit http://www.subversionary.org/
The changes are huge under the hood, and porting modules to forms API is non trivial.
Would it be better to call it 5.0?
While 4.7 has many changes, most of the changes are not visible to the user. In many ways 4.7.0 will be a "developer release". I'd prefer to reserve 5.0.0 for a "user release" that comes with more visual changes (eg. a new base theme and/or a new administration structure and/or CCK and/or workflows). Plus, we've been calling this 4.7.0 for 8 months or so. I'm worried that calling this 5.0.0 is going to confuse the heck out of people. It is going to render documentation/podcasts/videocasts outdated for sure. My 2 cents, -- Dries Buytaert :: http://www.buytaert.net/
Khalid B wrote:
(Crazy idea: should 4.7 be renamed 5.0? Would it be better to call it 5.0? It would have been, but with several beta's already released it's now too late. And besides if everyone listens to Adrian R. and implements his crazy/brilliant ideas 4.7 *will* look like a point release compared to 4.8... =D
-- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
It seems to me that it is too late, from the argument presented. Let us learn a lesson, and not do this in the future. Any major release should have a new major number, whether the changes are visible or not. Users keep mixing modules by mistake all the time, then ask why they break. It would be nice to have a guideline for release numbers with APIs not breaking between point releases, but do break between major ones. Just some thoughts for the future.
(Crazy idea: should 4.7 be renamed 5.0? Would it be better to call it 5.0? It would have been, but with several beta's already released it's now too late. And besides if everyone listens to Adrian R. and implements his crazy/brilliant ideas 4.7 *will* look like a point release compared to 4.8... =D
There a lot of crazy (yet cool) ideas shaping up for Drupal 4.8/5.0. People should already start preparing their patches; I hope to use much shorter development cycles in future aiming towards 2-3 releases a year. I'm thinking about trying a time-based release cycle, where development is frozen at a predefined date. It sounds like something worth evaluating. It doesn't hurt to give it a try. -- Dries Buytaert :: http://www.buytaert.net/
On 2/20/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
(Crazy idea: should 4.7 be renamed 5.0? Would it be better to call it 5.0? It would have been, but with several beta's already released it's now too late. And besides if everyone listens to Adrian R. and implements his crazy/brilliant ideas 4.7 *will* look like a point release compared to 4.8... =D
There a lot of crazy (yet cool) ideas shaping up for Drupal 4.8/5.0. People should already start preparing their patches; I hope to use much shorter development cycles in future aiming towards 2-3 releases a year. I'm thinking about trying a time-based release cycle, where development is frozen at a predefined date. It sounds like something worth evaluating. It doesn't hurt to give it a try.
A time based release cycle has merits. It should not be more than 2 a year (one every 6 months), since it will strain the community's resources. Ubuntu was founded because of the frustration with Debian's lengthy release cycle, and do it twice yearly.
My vote would be for 3 - four month cycles per year. On 2/20/06, Khalid B <kb@2bits.com> wrote:
On 2/20/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
(Crazy idea: should 4.7 be renamed 5.0? Would it be better to call it 5.0? It would have been, but with several beta's already released it's now too late. And besides if everyone listens to Adrian R. and implements his crazy/brilliant ideas 4.7 *will* look like a point release compared to 4.8... =D
There a lot of crazy (yet cool) ideas shaping up for Drupal 4.8/5.0. People should already start preparing their patches; I hope to use much shorter development cycles in future aiming towards 2-3 releases a year. I'm thinking about trying a time-based release cycle, where development is frozen at a predefined date. It sounds like something worth evaluating. It doesn't hurt to give it a try.
A time based release cycle has merits.
It should not be more than 2 a year (one every 6 months), since it will strain the community's resources.
Ubuntu was founded because of the frustration with Debian's lengthy release cycle, and do it twice yearly.
Too disruptive and resource intensive. People have sites to upgrade, modules to update, ...etc. If there is too much to do every 3 months, it will become a burden on everyone. Also, core developers have to put in time for making it happen, people have to test it, and Dries will go mad in no time. There is a reason Ubuntu timed it at 2 per year. Even once every 8 months is good, since it is more predictable. On 2/20/06, David Reed <dreed10@gmail.com> wrote:
My vote would be for 3 - four month cycles per year.
On 2/20/06, Khalid B <kb@2bits.com> wrote:
On 2/20/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
(Crazy idea: should 4.7 be renamed 5.0? Would it be better to call it 5.0? It would have been, but with several beta's already released it's now too late. And besides if everyone listens to Adrian R. and implements his crazy/brilliant ideas 4.7 *will* look like a point release compared to 4.8... =D
There a lot of crazy (yet cool) ideas shaping up for Drupal 4.8/5.0. People should already start preparing their patches; I hope to use much shorter development cycles in future aiming towards 2-3 releases a year. I'm thinking about trying a time-based release cycle, where development is frozen at a predefined date. It sounds like something worth evaluating. It doesn't hurt to give it a try.
A time based release cycle has merits.
It should not be more than 2 a year (one every 6 months), since it will strain the community's resources.
Ubuntu was founded because of the frustration with Debian's lengthy release cycle, and do it twice yearly.
On Mon, 20 Feb 2006 17:05:50 +0100, David Reed <dreed10@gmail.com> wrote:
My vote would be for 3 - four month cycles per year.
Then you need another security team leader. Supporting two releases with security -- it's a bit problematic but can be done. Three? We manage somehow. But four or six??
A BIG +1 on the idea of time-boxing the release cycles. I think this has a lot of benefits over the current approach. IMHO 1. It helps to create a sense of stability around the product. 2. It alleviates some (not all) of the when-will-release-X-be-done questions. 3. It helps businesses that rely on Drupal better plan their own Drupal-based initiatives 4. It adds a certain amount of structure to the development life-cycle 5. It helps contributors because knowing the schedule they can focus their efforts on the things that are most important to them for THAT release I know there are down-sides as well. I think the added structure would require more effort to manage. I've seen some OS projects employ a rotating release-coordinator so that burden is shared. Just my 2 cents. On 2/20/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
(Crazy idea: should 4.7 be renamed 5.0? Would it be better to call it 5.0? It would have been, but with several beta's already released it's now too late. And besides if everyone listens to Adrian R. and implements his crazy/brilliant ideas 4.7 *will* look like a point release compared to 4.8... =D
There a lot of crazy (yet cool) ideas shaping up for Drupal 4.8/5.0. People should already start preparing their patches; I hope to use much shorter development cycles in future aiming towards 2-3 releases a year. I'm thinking about trying a time-based release cycle, where development is frozen at a predefined date. It sounds like something worth evaluating. It doesn't hurt to give it a try.
-- Dries Buytaert :: http://www.buytaert.net/
David Reed wrote:
A BIG +1 on the idea of time-boxing the release cycles. I think this has a lot of benefits over the current approach.
IMHO
1. It helps to create a sense of stability around the product.
Huh? I've never thought of Drupal as being particularly unstable.
2. It alleviates some (not all) of the when-will-release-X-be-done questions.
Heh, here aren't that many of them. Nobody dares to ask twice.
3. It helps businesses that rely on Drupal better plan their own Drupal-based initiatives
Those mysterious businesses better go into a serious bug squashing frenzy if they want me to care for their problems.
4. It adds a certain amount of structure to the development life-cycle 5. It helps contributors because knowing the schedule they can focus their efforts on the things that are most important to them for THAT release
This doesn't make too much sense.
I know there are down-sides as well. I think the added structure would require more effort to manage. I've seen some OS projects employ a rotating release-coordinator so that burden is shared.
I am all in favour of release-early-release-often, but I don't care too much about the development model. The only thing I know is that there are a lot of people who could review or provide more patches... Cheers, Gerhard
Looks like there are two issues here, and two decisions that need to be made. 1. Shall we call CVS HEAD Drupal 4.7.0 or Drupal 5.0.0? Decision: we'll call it Drupal 4.7.0. Both 4.7.0 and 5.0.0 are flawed in one way or another, both are subject to opinion, we can't make everybody happy. Drupal 4.7.0 is inline with our release history, and the least disruptive change. 2. Shall we release a 'beta 5' or a 'release candidate'? Or; would we be comfortable shipping with the current set of known bugs? List of critical bugs: http://drupal.org/project/issues? projects=3060&versions=9902,9842,9753,9728,6487&categories=bug&prioritie s=1&states=1,8,13,14 Decision: undecided I won't release a new beta or RC this week. This week, I'll focus my efforts on (i) the drupal.org upgrade and (ii) reviewing/ committing patches. Let's make a decision by the end of the week and release early next week. Many of the critical bugs (see URL above) have patches that need to be reviewed, or that need to be worked on. Let's all focus on those, and decide based on this week's activity! I'm sure many of those are fairly straightforward to get in. Some of those might be around for several releases, and are probably less important at this point. (At the time of this writing there are 48 critical bugs left. That should give us a number to compare with.) -- Dries Buytaert :: http://www.buytaert.net/
On Mon, 2006-02-20 at 23:37 +0100, Dries Buytaert wrote:
Looks like there are two issues here, and two decisions that need to be made.
2. Shall we release a 'beta 5' or a 'release candidate'? Or; would we be comfortable shipping with the current set of known bugs?
List of critical bugs: http://drupal.org/project/issues? projects=3060&versions=9902,9842,9753,9728,6487&categories=bug&prioritie s=1&states=1,8,13,14
Decision: undecided
I'd like to see all of the 4.7 Release Critical bugs closed before a Release Candidate. Then we can figure out which non-critical bugs have the most impact on users, and focus on non-critcial bugs during the RC stage. Release Candidate to me is ready for production to the best of developers knowledge less unknown bugs, and trivialities (typos, misplaced ui elements). IE) functionally ready for production.
On Tue, 2006-02-21 at 00:46 +0100, Karoly Negyesi wrote:
I'd like to see all of the 4.7 Release Critical bugs closed before a Release Candidate.
Then close them!
Working on it sheesh... I though someone had elicited opinions about the rc vs beta issue again. I was just sharing mine. Review my stinking patches. I know the upload one needs work, but it would be nice to know if it was related to any other changes that have happened in the last few weeks. but yeah lets close all these bugs...
Dries, Karoly, and all. Can I suggest something? The list of bugs that are release critical, can we have a few core people (e.g. Dries, Steven and Karoly) go thru them and prioritize according to severity and complexity. For example, we can say severity (can't release without, can let it slip), and complexity (too much work, moderate, not reproducible, ...etc.) We then publish a list here to developers, and everyone takes one or two to try to fix. This may be too obvious, and redundant with the issues on Drupal, but having a team sift through what can wait and what must be fixed has merits, as well as give them visibility and ask people to address them. Worth a shot?
On 2/20/06, Khalid B <kb@2bits.com> wrote:
Can I suggest something?
The list of bugs that are release critical, can we have a few core people (e.g. Dries, Steven and Karoly) go thru them and prioritize according to severity and complexity.
I know I'm nobody but I spent some time re-prioritizing some bugs today.
For example, we can say severity (can't release without, can let it slip), and complexity (too much work, moderate, not reproducible, ...etc.)
We then publish a list here to developers, and everyone takes one or two to try to fix.
Dries already published a list of critical bugs at the start of this conversation. Why not start with the assumption that this is the list of issues which need to be resolved.
This may be too obvious, and redundant with the issues on Drupal, but having a team sift through what can wait and what must be fixed has merits, as well as give them visibility and ask people to address them.
Your suggestion would lead me to think that the current issue list is either too inaccurate or too large to bother looking at until someone with commit access waves the magic wand over each issue which has a chance of making release. I'll welcome their feedback where I can get it but we all have the capability to pick a few (more) issues from the critical list and either prioritize them down or provide some feedback where you have some. I'm no core dev but I can tell pretty easily (at this stage) what is likely to be accepted and what doesn't have a snowballs chance in hell. Let's save the committers' time for committing those patches! (hint, hint) Come on people...play bug bingo! http://drupal.org/bug-bingo Just my 0.2 sense
On Monday 20 February 2006 16:37, Dries Buytaert wrote:
2. Shall we release a 'beta 5' or a 'release candidate'? Or; would we be comfortable shipping with the current set of known bugs?
List of critical bugs: http://drupal.org/project/issues? projects=3060&versions=9902,9842,9753,9728,6487&categories=bug&prioritie s=1&states=1,8,13,14
Decision: undecided
I won't release a new beta or RC this week. This week, I'll focus my efforts on (i) the drupal.org upgrade and (ii) reviewing/
Right there is the answer. There's no way a 4.7-final should be released until drupal.org is already eating its own dogfood with a near-final 4.7. That's a pretty good stress test of the core system anyway. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
I won't release a new beta or RC this week. This week, I'll focus my efforts on (i) the drupal.org upgrade and (ii) reviewing/
Right there is the answer. There's no way a 4.7-final should be released until drupal.org is already eating its own dogfood with a near-final 4.7. That's a pretty good stress test of the core system anyway. :-)
Yes, that's why I want to upgrade drupal.org as soon as possible. Eating our own dogfood helps us evaluate the stability and scalability of Drupal 4.7.0. The following TODO list items have been taken care of the past week: 1. I synched http://scratch.drupal.org/ with http://drupal.org/ and upgraded it to CVS HEAD. 2. I spent some time to figure out why the donations page (http://drupal.org/donate) isn't updating. OSL had to recompile mod_php to fix the problem (curl-support was missing) but this is taken care of now. I still have to re-import the missing data though. I tried doing so but Paypal's export functionality was timing out. I'll try again later this week. 3. Kieran, his wife, webchick, Oadae et al. did a card sort on the Drupal 4.6 projects (http://drupal.org/node/50091). I wrote a small parser that takes the spreadsheet's information and turns it into SQL queries. The result can be seen at http://scratch.drupal.org/project/Modules. 4. Khalid and his wife ported 3 modules that we're using on drupal.org to CVS HEAD. They have been installed on http://scratch.drupal.org/ and seem to work fine. 5. Gerhard profiled the site, identified some expensive queries, and implemented some performance improvements. 6. I split the 'Hosting and services' forum in two separate forums and recategorized 150+ forum topics. What is left to do? 1. Update the drupal.org theme to CVS HEAD. I won't work on this but Steven Wittens will. As soon Steven is ready, we should be able to upgrade. -- Dries Buytaert :: http://buytaert.net/
Dries Buytaert wrote:
3. Kieran, his wife, webchick, Oadae et al. did a card sort on the Drupal 4.6 projects (http://drupal.org/node/50091). I wrote a small parser that takes the spreadsheet's information and turns it into SQL queries. The result can be seen at http://scratch.drupal.org/project/Modules.
This is a most excellent improvement. Many thanks to everyone who was involved in making it happen. -Robert
Robert Douglass wrote:
This is a most excellent improvement. Many thanks to everyone who was involved in making it happen. Indeed, though it'd be even better if the filter by version menu worked...
-- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
Robert Douglass wrote:
This is a most excellent improvement. Many thanks to everyone who was involved in making it happen.
This is a very good step to usability on Drupal.org. A long standing gripe is on its way to being addressed. Instead of "3rd party...", please make it "Third party.." so it is not the first thing on the top.
3. Kieran, his wife, webchick, Oadae et al. did a card sort on the Drupal 4.6 projects (http://drupal.org/node/50091). I wrote a small parser that takes the spreadsheet's information and turns it into SQL queries. The result can be seen at http://scratch.drupal.org/project/Modules.
This is a most excellent improvement. Many thanks to everyone who was involved in making it happen.
As a module maintainer, what influence do I have over the categorization given to my module? What is the right forum to ask about the logic behind the categorization? I like the categorized organization better than the gigantic list and it is indeed a very good addition. Scott
As a module maintainer, what influence do I have over the categorization given to my module?
While we're doing an initial bulk categorization to get us up to speed, after that categorizing will be done through a standard taxonomy multi-select on the module/theme's project node on drupal.org, when a project is created or updated. If you have edit access to that node (and the maintainer should), you'll be able to edit it. We may at that point wish to develop guidelines for module maintainers to refer to when categorizing their modules.
Robert Douglass pravi:
Dries Buytaert wrote:
3. Kieran, his wife, webchick, Oadae et al. did a card sort on the Drupal 4.6 projects (http://drupal.org/node/50091). I wrote a small parser that takes the spreadsheet's information and turns it into SQL queries. The result can be seen at http://scratch.drupal.org/project/Modules.
This is a most excellent improvement. Many thanks to everyone who was involved in making it happen.
-Robert
Can one choose how many modules to show per page? Tadej
The following TODO list items have been taken care of the past week:
1. I synched http://scratch.drupal.org/ with http://drupal.org/ and upgraded it to CVS HEAD.
2. I spent some time to figure out why the donations page (http://drupal.org/donate) isn't updating. OSL had to recompile mod_php to fix the problem (curl-support was missing) but this is taken care of now. I still have to re-import the missing data though. I tried doing so but Paypal's export functionality was timing out. I'll try again later this week.
3. Kieran, his wife, webchick, Oadae et al. did a card sort on the Drupal 4.6 projects (http://drupal.org/node/50091). I wrote a small parser that takes the spreadsheet's information and turns it into SQL queries. The result can be seen at http://scratch.drupal.org/project/Modules.
4. Khalid and his wife ported 3 modules that we're using on drupal.org to CVS HEAD. They have been installed on http://scratch.drupal.org/ and seem to work fine.
5. Gerhard profiled the site, identified some expensive queries, and implemented some performance improvements.
6. I split the 'Hosting and services' forum in two separate forums and recategorized 150+ forum topics.
What is left to do?
1. Update the drupal.org theme to CVS HEAD. I won't work on this but Steven Wittens will. As soon Steven is ready, we should be able to upgrade.
Steven finished updating the theme on http://scratch.drupal.org/. There are, however, a number of showstopping project module bugs: http://drupal.org/project/issues? projects=3281&states=1,2,8,13,14&priorities=1 -- Dries Buytaert :: http://www.buytaert.net/
Steven finished updating the theme on http://scratch.drupal.org/.
There are, however, a number of showstopping project module bugs: http://drupal.org/project/issues? projects=3281&states=1,2,8,13,14&priorities=1
I just spent some time looking at project.module bugs, tested and committed a couple patches, and provided a bugfix myself. The following issues need to be resolved before we can upgrade drupal.org: 1. http://drupal.org/node/50337 2. http://drupal.org/node/50786 3. http://drupal.org/node/50789 4. http://drupal.org/node/51432 These are high priority tasks as they hold back both the drupal.org upgrade and the Drupal 4.7.0 release. -- Dries Buytaert :: http://www.buytaert.net/
I just spent some time looking at project.module bugs, tested and committed a couple patches, and provided a bugfix myself. The following issues need to be resolved before we can upgrade drupal.org:
1. http://drupal.org/node/50337 2. http://drupal.org/node/50786 3. http://drupal.org/node/50789 4. http://drupal.org/node/51432
These are high priority tasks as they hold back both the drupal.org upgrade and the Drupal 4.7.0 release.
I synched scratch.drupal.org once more. Please spend some time testing out the project module functionality. Can you still update your project? Can you still edit issues? (I've yet to recreate the project categories.) Problems can be reported at http://drupal.org/project/issues/drupal_org_maintenance. -- Dries Buytaert :: http://buytaert.net/
I get this message, when browsing to http://scratch.drupal.org/cvs Warning: Invalid argument supplied for foreach() in /var/www/scratch.drupal.org/htdocs/modules/cvslog/cvs.module on line 255 Dries Buytaert pravi:
I just spent some time looking at project.module bugs, tested and committed a couple patches, and provided a bugfix myself. The following issues need to be resolved before we can upgrade drupal.org:
1. http://drupal.org/node/50337 2. http://drupal.org/node/50786 3. http://drupal.org/node/50789 4. http://drupal.org/node/51432
These are high priority tasks as they hold back both the drupal.org upgrade and the Drupal 4.7.0 release.
I synched scratch.drupal.org once more.
Please spend some time testing out the project module functionality. Can you still update your project? Can you still edit issues? (I've yet to recreate the project categories.) Problems can be reported at http://drupal.org/project/issues/drupal_org_maintenance.
-- Dries Buytaert :: http://buytaert.net/
On 03 Mar 2006, at 16:30, Tadej Baša wrote:
I get this message, when browsing to http://scratch.drupal.org/cvs
Warning: Invalid argument supplied for foreach() in /var/www/ scratch.drupal.org/htdocs/modules/cvslog/cvs.module on line 255
Fixed it. -- Dries Buytaert :: http://www.buytaert.net/
I just spent some time looking at project.module bugs, tested and committed a couple patches, and provided a bugfix myself. The following issues need to be resolved before we can upgrade drupal.org:
1. http://drupal.org/node/50337 2. http://drupal.org/node/50786 3. http://drupal.org/node/50789 4. http://drupal.org/node/51432
These are high priority tasks as they hold back both the drupal.org upgrade and the Drupal 4.7.0 release. I synched scratch.drupal.org once more. Please spend some time testing out the project module functionality. Can you still update your project? Can you still edit issues? (I've yet to recreate the project categories.) Problems can be reported at http://drupal.org/project/issues/drupal_org_maintenance.
I decided to postpone the drupal.org upgrade until we dealt with http://drupal.org/node/13148. We can't break thousands of links and need a clean upgrade path for our data. -- Dries Buytaert :: http://www.buytaert.net/
important at this point. (At the time of this writing there are 48 critical bugs left. That should give us a number to compare with.)
27 critical bugs left today. We're almost down to one page of critical bugs. Keep those patches coming. :-) -- Dries Buytaert :: http://buytaert.net/
release candidate++ 6 month pre-defined release schedule ++ Some thought will have to be given for how long a window should be open for new features. I'm thinking 3 months with the alpha released at that point. 4 months is the target for beta, 5 months target for release candidate. In the best scenario, we coast through the last week of the release candidate period wondering if any more bugs will be discovered. Drupal 5.0 would have seemed appropriate, but it's too late. -Robert Dries Buytaert wrote:
(Crazy idea: should 4.7 be renamed 5.0? Would it be better to call it 5.0?
It would have been, but with several beta's already released it's now too late. And besides if everyone listens to Adrian R. and implements his crazy/brilliant ideas 4.7 *will* look like a point release compared to 4.8... =D
There a lot of crazy (yet cool) ideas shaping up for Drupal 4.8/5.0. People should already start preparing their patches; I hope to use much shorter development cycles in future aiming towards 2-3 releases a year. I'm thinking about trying a time-based release cycle, where development is frozen at a predefined date. It sounds like something worth evaluating. It doesn't hurt to give it a try.
-- Dries Buytaert :: http://www.buytaert.net/
On Mon, Feb 20, 2006 at 04:25:21PM +0100, Dries Buytaert wrote:
People should already start preparing their patches; I hope to use much shorter development cycles in future aiming towards 2-3 releases a year. I'm thinking about trying a time-based release cycle, where development is frozen at a predefined date. It sounds like something
That was the plan for 4.7 IIRC, wasn't it? -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!
If people who are running the latest beta on their sites are not reporting show-stopping problems (and it does not seem that they are), then it should be a release candidate. I agree with Khalid: it ought to be called 5.0. It might not be psychologically wise to change names at this point, but if release numbers are to make any sense, any changes the size of what were made between 4.6 and 4.7 should really be major release number changes, e.g 4.6 -> 5.0, not point releases. ..chris Khalid B wrote:
+1 release candidate.
(Crazy idea: should 4.7 be renamed 5.0? I wonder why Drupal went so fast from 1.0 -> 4.x, then languished 4.x land for some long, years for 4.2, 4.3, 4.4, 4.5, 4.6 too long)
The changes are huge under the hood, and porting modules to forms API is non trivial.
Would it be better to call it 5.0?
(Ducks under the desk).
On 2/20/06, Moshe Weitzman <weitzman@tejasa.com> wrote:
Dries Buytaert wrote:
The tag (branch) doesn't exist yet. Creating the branch complicates matters as we have to commit each patch twice. I wanted to create the branch as soon we release a 'release candidate'. Talking of which, should we release another beta (beta 5) or should we go straight to a release candidate? release candidate
between 4.6 and 4.7 should really be major release number changes, e.g 4.6 -> 5.0, not point releases.
I disagree. If I can simplify the last six months of work: FormAPI or, as I prefer, FAPI. Security/validation related to FAPI This is a framework/API "developer feature", and not something that the end-user will ever care to appreciate. Taking FAPI out of the equation, I don't really see the number of *important* features that would make justify a 5.0 release. -- Morbus Iff ( and think about the bad things that I didn't do ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 20 Feb 2006, at 17:56, Morbus Iff wrote:
I disagree. If I can simplify the last six months of work:
FormAPI or, as I prefer, FAPI. Security/validation related to FAPI
This is a framework/API "developer feature", and not something that the end-user will ever care to appreciate. Taking FAPI out of the equation, I don't really see the number of *important* features that would make justify a 5.0 release.
As indicated earlier, I agree with Morbus' statement. For developers, 4.7.0 is a significant change. For users, it is not. Calling something 5.0.0 sets a lot of expectations. For the average user, an improved default core theme, written in two days, is much more exciting than the forms API we have been working on for many months. For the next release, I want to us to introduce a dashboard, create a new default core theme, reorganize the administration pages, and hopefully include an install system. By doing so, we have all the ingredients it takes to release a 5.0.0 and to live up people's expectations. -- Dries Buytaert :: http://www.buytaert.net/
As indicated earlier, I agree with Morbus' statement. For developers, 4.7.0 is a significant change. For users, it is not. Calling something 5.0.0 sets a lot of expectations. For the average user, an improved default core theme, written in two days, is much more exciting than the forms API we have been working on for many months.
For the next release, I want to us to introduce a dashboard, create a new default core theme, reorganize the administration pages, and hopefully include an install system. By doing so, we have all the ingredients it takes to release a 5.0.0 and to live up people's expectations.
I hear you, and agree with your reasoning. But, there is another side to release numbers. Release numbers that are close are thought to be more similar, compatible, ...etc. By making numbers close, we fool people (unintentionally of course) into running 4.5 modules on 4.6 ("It can't be that different, can it?"), then they ask in the forums or send emails to developers when things break. With 4.7 we have made it worse. Not disputing your points, they are totally valid, but there is another angle that I wanted to share.
On 2/20/06, Morbus Iff <morbus@disobey.com> wrote:
between 4.6 and 4.7 should really be major release number changes, e.g 4.6 -> 5.0, not point releases.
I disagree. If I can simplify the last six months of work:
FormAPI or, as I prefer, FAPI. Security/validation related to FAPI
This is a framework/API "developer feature", and not something that the end-user will ever care to appreciate. Taking FAPI out of the equation, I don't really see the number of *important* features that would make justify a 5.0 release.
Morbus The impact of under the hood changes does affect end users, but in an indirect way. - Modules: Many would not work at all between point releases because the API is broken. - Upgrades: Significant database changes affect upgrade and modules as well. So, even though they do not see tangible things in Drupal, the version number sends a message for compatibility, ...etc.
The impact of under the hood changes does affect end users, but in an
The only users this would effect, with your comments about version numbers indicating "close" compatibility, would be brand new users who have never had to upgrade a Drupal before. It has been Drupal's policy, for as long as I've been with the project, to never worry about backwards compatibility, and every single release I've ever used has always needed new and updated modules. Thus, I don't find your argument strong, really - it merely highlights a (desired) downside we've been enforcing on our users through any point release for at least two years. -- Morbus Iff ( take your rosaries off my ovaries ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Morbus Iff wrote:
between 4.6 and 4.7 should really be major release number changes, e.g 4.6 -> 5.0, not point releases.
I disagree. If I can simplify the last six months of work:
FormAPI or, as I prefer, FAPI. Security/validation related to FAPI
This is a framework/API "developer feature", and not something that the end-user will ever care to appreciate. Taking FAPI out of the equation, I don't really see the number of *important* features that would make justify a 5.0 release.
Whether the changes are to the end user is only a part of the equation. The revision number of the software should provide a general guideline to all audiences as to how much of a change a particular release contains. End users who can "see" the change are only one member of the set of all audiences. Members of those audiences might include: 1. Drupal core developers 2. Drupal module developers 3. Drupal theme developers 4. Consultants 5. Site developers 6. Site administrators 7. IT administrators 8. Site owner entity management (e.g. NGO boards or for-profit management) 9. End users 10. Etc. All of these people need to know something has changed. One might argue that End Users themselves have the least need to be notified, since they will either "see" the difference -- or they won't. Morbus' argument that most of the 4.7 changes are "developer features" (and therefore the revision number need not reflect their scope) leaves out the other audiences. Consultants need to know how big a change it might mean to their current clients. Site developers need to know which version to target for a site that has to go live in 4 weeks, and they need to know how much effort it's going to take to upgrade from 4.6 to 4.7 to correctly make that decision. IT administrators and Site Owners need to know that 4.6 to 4.7 is a big change so that they can manage their resources, schedule their upgrades and plan their next 6 to 12 months of system, network, site and related software activity. Drupal sites don't exist in a vacuum, especially not anymore. Managing a Drupal-based website often means more than worrying about the Drupal version. Bryght is plugged in technically and won't have a problem. But it's just as possible that other organizations have made similar large commitments to using Drupal, and they may not be as plugged in. They need a BIG Red Sign in the form of a major release number to let them know that 4.7 is dramatically different "under the hood" from 4.6, and that upgrading is going to take lots of manpower. The Form API change should have made 4.7 be named 5.0. It's too late to rename it, but the revision numbers should be in accord with that kind thinking, contrary to what Morbus argues. ..chris
Agree!!!! Even after 4.7 drops, the contribs that I depend on won't be ready for at least a while. Currently they are very badly marked as to which version they work with. The release policy must take the contribs into account. You can't turn the releases unless the contribs can keep up. There are lots of remarks about things that work with PHP 4 or 5, but none about things that work with MySQL 4 or 5. Dreamhost just went to MySQL5 and I am stuck badly. So changes in these two which have no reason to folllow the Drupal schedule have to be factored into possible Drupal schedules. I have a tight deadline of getting off my current ISP (which dies March 29) and onto Dreamhost. Drupal 4.6 does not work with MySQL 5 and 4.7 + its contribs is not likely to be ready for production.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Chris Johnson Sent: Monday, February 20, 2006 3:09 PM To: development@drupal.org Subject: Re: [development] no 4-7-0 branch for core yet?
Morbus Iff wrote:
between 4.6 and 4.7 should really be major release number changes, e.g 4.6 -> 5.0, not point releases.
I disagree. If I can simplify the last six months of work:
FormAPI or, as I prefer, FAPI. Security/validation related to FAPI
This is a framework/API "developer feature", and not something that the end-user will ever care to appreciate. Taking FAPI out of the equation, I don't really see the number of *important* features that would make justify a 5.0 release.
Whether the changes are to the end user is only a part of the equation. The revision number of the software should provide a general guideline to all audiences as to how much of a change a particular release contains. End users who can "see" the change are only one member of the set of all audiences.
Members of those audiences might include: 1. Drupal core developers 2. Drupal module developers 3. Drupal theme developers 4. Consultants 5. Site developers 6. Site administrators 7. IT administrators 8. Site owner entity management (e.g. NGO boards or for-profit management) 9. End users 10. Etc.
All of these people need to know something has changed. One might argue that End Users themselves have the least need to be notified, since they will either "see" the difference -- or they won't.
Morbus' argument that most of the 4.7 changes are "developer features" (and therefore the revision number need not reflect their scope) leaves out the other audiences.
Consultants need to know how big a change it might mean to their current clients. Site developers need to know which version to target for a site that has to go live in 4 weeks, and they need to know how much effort it's going to take to upgrade from 4.6 to 4.7 to correctly make that decision.
IT administrators and Site Owners need to know that 4.6 to 4.7 is a big change so that they can manage their resources, schedule their upgrades and plan their next 6 to 12 months of system, network, site and related software activity.
Drupal sites don't exist in a vacuum, especially not anymore. Managing a Drupal-based website often means more than worrying about the Drupal version.
Bryght is plugged in technically and won't have a problem. But it's just as possible that other organizations have made similar large commitments to using Drupal, and they may not be as plugged in. They need a BIG Red Sign in the form of a major release number to let them know that 4.7 is dramatically different "under the hood" from 4.6, and that upgrading is going to take lots of manpower.
The Form API change should have made 4.7 be named 5.0. It's too late to rename it, but the revision numbers should be in accord with that kind thinking, contrary to what Morbus argues.
..chris
I am running drupal 4.6 on mysql 5, with standard configs. I'm wondering if people having this trouble aren't doing something to my.cnf or during compilation? --mark On 2/20/06, Walt Daniels <wdlists@optonline.net> wrote:
Agree!!!! Even after 4.7 drops, the contribs that I depend on won't be ready for at least a while. Currently they are very badly marked as to which version they work with. The release policy must take the contribs into account. You can't turn the releases unless the contribs can keep up.
There are lots of remarks about things that work with PHP 4 or 5, but none about things that work with MySQL 4 or 5. Dreamhost just went to MySQL5 and I am stuck badly. So changes in these two which have no reason to folllow the Drupal schedule have to be factored into possible Drupal schedules. I have a tight deadline of getting off my current ISP (which dies March 29) and onto Dreamhost. Drupal 4.6 does not work with MySQL 5 and 4.7 + its contribs is not likely to be ready for production.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Chris Johnson Sent: Monday, February 20, 2006 3:09 PM To: development@drupal.org Subject: Re: [development] no 4-7-0 branch for core yet?
Morbus Iff wrote:
between 4.6 and 4.7 should really be major release number changes, e.g 4.6 -> 5.0, not point releases.
I disagree. If I can simplify the last six months of work:
FormAPI or, as I prefer, FAPI. Security/validation related to FAPI
This is a framework/API "developer feature", and not something that the end-user will ever care to appreciate. Taking FAPI out of the equation, I don't really see the number of *important* features that would make justify a 5.0 release.
Whether the changes are to the end user is only a part of the equation. The revision number of the software should provide a general guideline to all audiences as to how much of a change a particular release contains. End users who can "see" the change are only one member of the set of all audiences.
Members of those audiences might include: 1. Drupal core developers 2. Drupal module developers 3. Drupal theme developers 4. Consultants 5. Site developers 6. Site administrators 7. IT administrators 8. Site owner entity management (e.g. NGO boards or for-profit management) 9. End users 10. Etc.
All of these people need to know something has changed. One might argue that End Users themselves have the least need to be notified, since they will either "see" the difference -- or they won't.
Morbus' argument that most of the 4.7 changes are "developer features" (and therefore the revision number need not reflect their scope) leaves out the other audiences.
Consultants need to know how big a change it might mean to their current clients. Site developers need to know which version to target for a site that has to go live in 4 weeks, and they need to know how much effort it's going to take to upgrade from 4.6 to 4.7 to correctly make that decision.
IT administrators and Site Owners need to know that 4.6 to 4.7 is a big change so that they can manage their resources, schedule their upgrades and plan their next 6 to 12 months of system, network, site and related software activity.
Drupal sites don't exist in a vacuum, especially not anymore. Managing a Drupal-based website often means more than worrying about the Drupal version.
Bryght is plugged in technically and won't have a problem. But it's just as possible that other organizations have made similar large commitments to using Drupal, and they may not be as plugged in. They need a BIG Red Sign in the form of a major release number to let them know that 4.7 is dramatically different "under the hood" from 4.6, and that upgrading is going to take lots of manpower.
The Form API change should have made 4.7 be named 5.0. It's too late to rename it, but the revision numbers should be in accord with that kind thinking, contrary to what Morbus argues.
..chris
-- mark burdett mark@goodstorm.com +1 (415) 341-2815 [mobile] +1 (415) 223-0305 [office] http://www.goodstorm.com/ 835 Terry Francois St San Francisco CA 94158-2209
I don't have any control over what version of MySQL DreamHost runs, nor over what is in my.cnf. There are known bugs in Drupal, in particular image, events and taxonomy, which use SQL statements that unconforming to recent standards that MySQL just started enforcing. So if you are running on 4.6 you are lucky or not using any of the above modules.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of mark burdett Sent: Monday, February 20, 2006 4:23 PM To: development@drupal.org Cc: chris@tinpixel.com Subject: Re: [development] no 4-7-0 branch for core yet?
I am running drupal 4.6 on mysql 5, with standard configs. I'm wondering if people having this trouble aren't doing something to my.cnf or during compilation?
--mark
On Mon, 20 Feb 2006 22:15:05 +0100, Walt Daniels <wdlists@optonline.net> wrote:
Agree!!!! Even after 4.7 drops, the contribs that I depend on won't be ready for at least a while. Currently they are very badly marked as to which version they work with. The release policy must take the contribs into account. You can't turn the releases unless the contribs can keep up.
There are lots of remarks about things that work with PHP 4 or 5, but none about things that work with MySQL 4 or 5. Dreamhost just went to MySQL5 and I am stuck badly. So changes in these two which have no reason to folllow the Drupal schedule have to be factored into possible Drupal schedules. I have a tight deadline of getting off my current ISP (which dies March 29) and onto Dreamhost. Drupal 4.6 does not work with MySQL 5 and 4.7 + its contribs is not likely to be ready for production.
I'm using 4.6.5 on Dreamhost without problems (that I know of).... Care to elaborate? -- Tim Altman
See http://drupal.org/node/43735#comment-92865 , dependent on 5.13+ release.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Tim Altman Sent: Monday, February 20, 2006 4:40 PM To: development@drupal.org Subject: Re: [development] no 4-7-0 branch for core yet?
On Mon, 20 Feb 2006 22:15:05 +0100, Walt Daniels <wdlists@optonline.net> wrote:
Agree!!!! Even after 4.7 drops, the contribs that I depend on won't be ready for at least a while. Currently they are very badly marked as to which version they work with. The release policy must take the contribs into account. You can't turn the releases unless the contribs can keep up.
There are lots of remarks about things that work with PHP 4 or 5, but none about things that work with MySQL 4 or 5. Dreamhost just went to MySQL5 and I am stuck badly. So changes in these two which have no reason to folllow the Drupal schedule have to be factored into possible Drupal schedules. I have a tight deadline of getting off my current ISP (which dies March 29) and onto Dreamhost. Drupal 4.6 does not work with MySQL 5 and 4.7 + its contribs is not likely to be ready for production.
I'm using 4.6.5 on Dreamhost without problems (that I know of).... Care to elaborate?
-- Tim Altman
On Mon, 2006-02-20 at 14:08 -0600, Chris Johnson wrote:
Morbus Iff wrote:
between 4.6 and 4.7 should really be major release number changes, e.g 4.6 -> 5.0, not point releases.
I disagree. If I can simplify the last six months of work:
FormAPI or, as I prefer, FAPI. Security/validation related to FAPI
This is a framework/API "developer feature", and not something that the end-user will ever care to appreciate. Taking FAPI out of the equation, I don't really see the number of *important* features that would make justify a 5.0 release.
Whether the changes are to the end user is only a part of the equation. The revision number of the software should provide a general guideline to all audiences as to how much of a change a particular release contains. End users who can "see" the change are only one member of the set of all audiences.
Members of those audiences might include: 1. Drupal core developers 2. Drupal module developers 3. Drupal theme developers 4. Consultants 5. Site developers 6. Site administrators 7. IT administrators 8. Site owner entity management (e.g. NGO boards or for-profit management) 9. End users 10. Etc.
All of these people need to know something has changed. One might argue that End Users themselves have the least need to be notified, since they will either "see" the difference -- or they won't.
Morbus' argument that most of the 4.7 changes are "developer features" (and therefore the revision number need not reflect their scope) leaves out the other audiences.
Consultants need to know how big a change it might mean to their current clients. Site developers need to know which version to target for a site that has to go live in 4 weeks, and they need to know how much effort it's going to take to upgrade from 4.6 to 4.7 to correctly make that decision.
IT administrators and Site Owners need to know that 4.6 to 4.7 is a big change so that they can manage their resources, schedule their upgrades and plan their next 6 to 12 months of system, network, site and related software activity.
Drupal sites don't exist in a vacuum, especially not anymore. Managing a Drupal-based website often means more than worrying about the Drupal version.
Bryght is plugged in technically and won't have a problem. But it's just as possible that other organizations have made similar large commitments to using Drupal, and they may not be as plugged in. They need a BIG Red Sign in the form of a major release number to let them know that 4.7 is dramatically different "under the hood" from 4.6, and that upgrading is going to take lots of manpower.
The Form API change should have made 4.7 be named 5.0. It's too late to rename it, but the revision numbers should be in accord with that kind thinking, contrary to what Morbus argues.
..chris
You know I have to strongly disagree with the hubbabbaloo.... Most software groups have their own guidelines for the versioning, which grew from a community process... Generally speaking versioning basically goes something like changes to more significant digits(those on the left) indicate a greater change in the program. I think for drupal most people who pay attention or read a little bit, quickly figure out. X.Y.Z Z changes = bug fixes and compatable... Y changes = some pretty big stuff went down, you got some neat features, and modules will have to be updated, menu's have been re-arranged. Upgrade with caution.. Z changes = a whole new beast... The hooks were replace by form callbacks or something similar. Drupal is now a dynamic XML transformed by dynamic XSL into whatevery buzzword you want... be ready to invest a good bit of time in figuring out what has changed. Only trace elements will be familiar... ps... everyone else was talking I had to say something..
On 20-Feb-06, at 11:56 AM, Morbus Iff wrote:
between 4.6 and 4.7 should really be major release number changes, e.g 4.6 -> 5.0, not point releases.
I disagree. If I can simplify the last six months of work:
FormAPI or, as I prefer, FAPI. Security/validation related to FAPI
This is a framework/API "developer feature", and not something that the end-user will ever care to appreciate. Taking FAPI out of the equation, I don't really see the number of *important* features that would make justify a 5.0 release.
well, the xtemplate -> phptemplate switch (yeah, I forgot that was this cycle too) will also create an OMGWTF reaction with a bunch of people (probably the ton of drupal admins not on this list). Personally, I'm not worried about it... but I knew (or had a good idea) it was coming and had already made the switch... but a quick show of hands at the last toronto drupal user group meetup made me realize that there are those who still use xtemplate. Again, this isn't really a "user feature" - although, it's arguably not really a "developer feature" as well. My case for version numbering would be tied to backwards compatibility ... but then, Drupal would be somewhere around version 62.0.2 by now. ;) -- James Walker :: http://walkah.net/
On Monday 20 February 2006 15:44, James Walker wrote:
well, the xtemplate -> phptemplate switch (yeah, I forgot that was this cycle too) will also create an OMGWTF reaction with a bunch of people (probably the ton of drupal admins not on this list). Personally, I'm not worried about it... but I knew (or had a good idea) it was coming and had already made the switch... but a quick show of hands at the last toronto drupal user group meetup made me realize that there are those who still use xtemplate.
Silly question -- is it too late to include an updated "xtemplate" with 4.7 Drupal core, but make it VERY CLEAR (such as in the Admin...Themes dialog screen) that xtemplate is deprecated and will go away *next* release? Or is this a stupid idea? Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/
On 2/21/06, Syscrusher <syscrusher@4th.com> wrote:
Silly question -- is it too late to include an updated "xtemplate" with 4.7 Drupal core, but make it VERY CLEAR (such as in the Admin...Themes dialog screen) that xtemplate is deprecated and will go away *next* release?
XTemplate is removed from 4.7 core, but that doesn't mean that someone can't commit it to contrib, and maintain it for the next 10 releases. I don't see XTemplate in contrib yet, but all it will take is one developer who won't / can't upgrade his XTtemplate themes (don't look at me!), and it will be there for 4.7. When that happens, site admins will be able to run their old XTemplate themes just fine in 4.7. Jaza.
developer who won't / can't upgrade his XTtemplate themes (don't look
won't. As the upgrading can be done half-dead (I suspect it's even scriptable but noone took the effort) http://drupal.org/node/22019 the "can't" is unlikely.
On 2/20/06, Chris Johnson <chris@tinpixel.com> wrote:
If people who are running the latest beta on their sites are not reporting show-stopping problems (and it does not seem that they are), then it should be a release candidate.
Well, since you mention it, file uploads in HEAD seem to be in bad shape at the moment. http://drupal.org/node/5961 http://drupal.org/node/43220 http://drupal.org/node/49675 http://drupal.org/node/50266
matters as we have to commit each patch twice. I wanted to create the branch as soon we release a 'release candidate'. Talking of which, should we release another beta (beta 5) or should we go straight to a release candidate?
+1 for beta 5. I don't see how this can be a release candidate when the first page of the upgrade system still spits out 2-3 warnings and (as of two days ago) the JS upgrade isn't working - comes up with an error pop-up (switching JS off solves the issue). Coupled with the "node/locale search" issue that chx is working on and stuff like "deleting user cripples nodes", "taxonomies are lost on revert" etc. there is enough of a case IMO for this not to be a RC (yet). I'm not sure what the yardstick is, but IMO these are all serious breaks in functionality.. Moreover, the above are only the issues *I* am immediately aware of. There very likely are more. I think it might be worthwhile to also consider the following (by no means conclusive, but perhaps indicative?) stats: Issues marked b4 = 68 Issues marked b3 = 52 Issues marked b2 = 36 Issues marked b1 = 25 The above include active, patch, fixed and closed. My 10p, -K P.S I'm assuming here that "Release Candidate" indicates a feature complete release which the developers (after *rigorous* internal/beta testing) have deemed to be good enough for public release, but are inviting feedback from production sites..
participants (28)
-
Adrian Simmons -
Chris Cook -
Chris Johnson -
Darrel O'Pry -
David Reed -
Dries Buytaert -
Dries Buytaert -
drupal＠mclewin.com -
Gabor Hojtsy -
Gerhard Killesreiter -
Gordon Heydon -
James Walker -
Jeremy Epstein -
Karoly Negyesi -
Karthik -
Khalid B -
Larry Garfield -
mark burdett -
Martin Tomes -
Morbus Iff -
Moshe Weitzman -
Nedjo Rogers -
piotr＠mallorn.ii.uj.edu.pl -
Robert Douglass -
Syscrusher -
Tadej Baša -
Tim Altman -
Walt Daniels