| Project: | Node Hierarchy |
| Version: | 6.x-2.0 |
| Component: | Miscellaneous |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I'd really like to see us move towards having the 6.x-2.x version of the module be the official version we recommend for users. For quite some time it's been the almost exclusive focus of development and it is a significant improvement over the 1.x version. Lots of us are using 2.x in production sites, and we ought to do ourselves and our users a favor by establishing a stable, safe 2.0 to work from. Accordingly, I'd like to suggest that we prioritize any existing serious ('critical', perhaps?) bugs, make sure the upgrade from 1.x is working well and then release a 2.0.
Ideally, I'd like to see the 2.0 be as close the the current 6.x-2.x as possible - really just tackling serious bugs and/or roadblocks to making 6.x-2.0 the baseline standard used by all. More specifically, I think we ought to focus solely on bug reports (vs. feature requests) and keep functionality stable.
I think this does a number of things for everyone; gives us all a static, stable, safe baseline to work with. Gives the developers the freedom to re-factor and/or significantly improve functionality - possibly breaking things in the process - without the fear that someone might update and deploy the code unknowingly.
If this meets with approval - I suggest we prioritize issues that need to be handled - flag them as critical (e.g. I'm thinking of things like #883604: Fully supporting and integrating PathAuto and Token) and downgrade anything else.
To be clear, this is just my opinion - I've been meaning to share with everyone and look for feedback as I think more clarity on the forward path would be good for all.
Comments
#1
I think it would be a shame not to incorporate some of markcarver's and jbylsma's amazing patches, ideas and hard work.
#2
Well - that's exactly the discussion I want to have. Both have put a lot of work in - which is awesome. It's scary to commit major things now, though, because the dev branch is actually the prod branch for lots of us. So - essentially - I think we need to do some housekeeping so that we can have a safe dev branch to get new ideas and code in, test thoroughly and then incorporate into future stable releases.
#3
I agree with everything that has been said thus far. And yes I use the dev for my (14) multisite production installation as well. However I would again like to stress that the changes I have made are almost strictly EDIT:
cosmetic allowingenhancing with new features and a stricter variable naming convention via an update.Anytime there is a bug that I encounter, I immediately fix it on my site EDIT: (for testing purposes) then create a patch against the dev accordingly. Although it's becoming difficult to keep this up because I am using a LOT of these new features which has mostly come from how I have setup my multisite and it's need for these features. It would be nice and much easier to commit bug fixes against a dev version that is up to date with my own production site. I do not wish to fork this module, because that's never a good solution.
I propose that we go ahead and release a "beta1" version of 2.0 based on the current dev. Encourage those who are using the current dev version and who aren't interested in being guinea pigs to install this new "beta1" version. For the most part, this "beta1" would be considered a working production version as like you said.
We can then turn the dev version back into what it's meant to be: a development version. Not used for production and sometimes unstable. Then these new patches and bug fixes can be patched. I like to commit changes and these changes don't have to be "as-is". But I like to think that these features are needed. That's the beauty of active development, you can see the changes in real time and make adjustments as we see fit and as new ideas/issues present themselves.
We will need to change the project page and clearly define what the versions are intended for and also make sure we include releases with appropriate verbiage stating what changes have been made.
This can be scary, I agree. But I think it's necessary. Necessity is the mother of invention and NH has become a very robust module... and it's going through a growing spurt! We just have to make sure we mark the wall where it's needed.
#4
Any thoughts on this?
#5
Thanks all for the input. I agree that getting to a stable release is a high priority. I've left it waaaaaaaay too long in dev.
From my understanding, the 2 major outstanding changes are:
The token/pathauto stuff #811274: Recursive Pathauto for 6-x-2.x and "Add Children Only", #950882: Cleanup of nodehierarchy_token.inc
And the extra options and ui overhaul in #921198: Rework administration and node create/edit with new features and clean design
It sounds like the pathauto stuff is necessary to keep the current level so that should be a priority for a 2.0 release. The larger overhaul is a little less clear for me. There seem to be a number of things going on in that largish patch so I'll need, at the very least, to piece my way through it and figure out all the new features it's adding and how they're working so that I can support them going forward.
My sense is that if we commit to getting #921198: Rework administration and node create/edit with new features and clean design into a stable release then we will delay that release. On the other hand, if the db changes in the patch are necessary, then it'd probably be better to get it in before the release.
Does this make sense
#6
Yes this makes perfect sense! I am certainly one for enforcing naming conventions, especially when you have so many different variables in play or soon to be in play. Tomorrow, I can separate the update and the related variable names through out the patch from that of the new features (with the exception of also including this quick fix: #965490: Upper limit for children when sorting?). This way we can go ahead and release what is now the dev version as "2.0-rc1" or "2.0-beta1"... not sure what would be more appropriate. It should NOT be marked as "recommended", this allows the release to display as yellow (see end for standards).
Essentially this is, in my opinion, the first step we should take to get Node Hierarchy back on track. It will allow everyone whom uses the current dev version for their production sites to remain stable. This will also allow us developers to commit these patches at our leisure in the appropriate venue, the development version.
The dev version should allow us as developers to implement features/ideas and work out bugs that take time and effort with out the threat of breaking a site. And those who use this version should know that it, at times, can be very unstable and are encouraged to report these bugs so we can work on the problem. Once we come to a point in the dev version where we all agree that it is stable enough to make another release, we can continue to with "2.0-rc2" and so forth.
Ultimately, yes we need a stable (green) "2.0" release. However, as you mentioned, the following three issues should be fully addressed before we can move towards this major release:
#883604: Fully supporting and integrating PathAuto and Token
#811274: Recursive Pathauto for 6-x-2.x and "Add Children Only"
#921198: Rework administration and node create/edit with new features and clean design
After those are implemented, I think that was can release any new features or bug fixes as patch releases (2.1, 2.2, 2.3, etc.).
Also, I'm sure we've all read these at one point, but I think it certainly wouldn't hurt to reiterate them to help us remember the protocols established for development of Drupal modules:
http://drupal.org/handbook/cvs/releases/types
http://drupal.org/node/197584
#7
Another thing, we should reflect the differences of the versions on the project's main page to inform everyone what goals are to be accomplished.
#8
Here is the variable renaming update and the code changes that go with it.
#9
Another thought, what are the plans for the 6.x-1.x branch when we release 2.0? Are we going to continue to port things back when stuff like #883604: Fully supporting and integrating PathAuto and Token happens? Or are we going to stop all support and force everyone to upgrade to the 6.x-2.x branch?
What about this issues as well, most of them are for various versions of the 6.x-1.x branch. What is our goal here?
#10
My $.02
I think we ought to resolve the criticals in 6.x-1.x as well, release a stable there (6.x-1.4), verify the upgrade path and then depricate after that - turn 2.0 into the supported release and move forward. Another cleanup item to do at that time will be to verify that the 5.x to 6.x upgrade works as well -- and possibly doing a final release in 5.x if necessary at that point.
#11
Well, I'll be honest, I don't know too much about the 6x-1.x branch, but I suspect just from looking at the issues that a lot of them are feature requests. I think those can be moved to the 6.x-2.x branch, what do you think?
I agree with you that we should solidify the versions and just move forward. After this PathAuto/Token patch and along the patch above (for renaming variables), do you think we could go ahead and officially create a 6.x-2.0-beta1 so we can open up the dev?
#12
Agreed - any feature requests in 6.x-1.x should be moved to 6.x-2.x. In terms of blockers for a 6.x-2.0 -- I think we should make sure #883604: Fully supporting and integrating PathAuto and Token is resolved - but that may be it.
Per ronan at #5 above, #811274: Recursive Pathauto for 6-x-2.x and "Add Children Only", looks like another priority - but I'm not sure anyone has a patch that applies. Also per #5 #921198: Rework administration and node create/edit with new features and clean design - sounds like it may be better suited to address after a 2.0? (That's my reading, at least)
If this is right, then, I think we're almost there. Shall we go through, verify priorities and make sure nothing else critical is hiding? http://drupal.org/project/issues/nodehierarchy?text=&status=Open&priorit... If not, and the patch token/pathauto patch holds, I plan to go back and focus on 6.x-1.x queue and upgrade path - moving features to 2.x, fixing anything critical and doing a last release if necessary and then verifying the 1.x -> 2.x upgrade path.
#13
Wow, things really ramping up! Great to see all the work going on.
As for critical things, I realized that my overzealous JS patch from #936006: Allow menu settings to be customized if the content type's "Show item in menu" is set to "Always", which Mark marked as a duplicate of #809542: Menu options hidden when "show item in menu" set to "always", should probably be addressed, at least as a "major" issue. Without them, there is no way to customize the menu for content types with "Show item in menu" as always. I can re-roll my patch without all the JS changes, if it would help.
As for #811274: Recursive Pathauto for 6-x-2.x and "Add Children Only", I'd done some preliminary investigation based on djac's comments in #8, but ran into issues with determining custom paths within /admin/build/menu-customize and some infinite loops on hook_menu_link_alter. The module hasn't been integrated with node_hierarchy's core module but could easily be placed inside the node_hierarchy directory like nodehierarchyaccess or nodehierarchy_views. No promises, but I should be able to put some serious work in tomorrow night to get it to a commitable place. I'll also add some more detailed comments over there.
#14
If you read #6, I replied to ronan's #5. What he was saying is that if we are going to rename the variables, we should do it before we make an official 2.0 release. Which I did so in the patch above. I separated the update and variable renaming from #921198: Rework administration and node create/edit with new features and clean design. This way once #883604: Fully supporting and integrating PathAuto and Token is fixed, we can go ahead and release 2.0 and not have to worry about breaking anything with the dev. I can this commit #921198: Rework administration and node create/edit with new features and clean design and it can go under testing without fear of breaking anything. In a sense, yes this would be after 2.0... probably a 2.1 release if you will. But we need to go ahead and release 2.0 first before I can do anything with the dev. If you are on skype (marcuscarver) or iChat (mark.carver@me.com) I would like to chat via IM so we can talk in real time and avoid this kind of miscommunication via the issue forum.
#15
Afterthought, in regards to #13:
I think that I shouldn't have renamed the issue #883604: Fully supporting and integrating PathAuto and Token. This is a specific bug, not for new features. What I was trying to do, and can now see that we should either rename #811274: Recursive Pathauto for 6-x-2.x and "Add Children Only" or create a new issue, is to fully utilize PathAuto and Token. As it stands, we provide very basic support when in reality we can offer sooo much more.
As for #809542: Menu options hidden when "show item in menu" set to "always", I do believe that this should really be addressed in #921198: Rework administration and node create/edit with new features and clean design. Relying on JS is bad form when this can be accomplished via Drupal's form building by using a simple disabled (checked) checkbox. This way the menu item options are visible. There is a time and place for JS, but this isn't one of them. I would actually hold off on patching/working on NH's JS until a more set admin/node edit interface is established. For now, please continue using your custom patch until this can be properly addressed.
#16
Just a quick heads up: I've posted a patch at #811274: Recursive Pathauto for 6-x-2.x and "Add Children Only" that integrates the recursive pathauto into the nodehierarchy.module file.
#17
Ok - that is working for me as well, but I still want to test more. I like the idea of getting this into the 6.x-2.0 release, but I really want to be more sure of the overall consequences and do some more testing -- things work in my limited test cases as-is - but I don't have enough complexity in there to be confident. Accordingly, I've rerolled a patch that _may_ be right for to 2.0 -- still not committing it as I've now combined a few issues, including:
#883604: Fully supporting and integrating PathAuto and Token
#811274: Recursive Pathauto for 6-x-2.x and "Add Children Only" + some code cleaning
#576968: 6.x-1.x -> 6.x-2.x Upgrade Path
I'm concerned about slippage here though - I'd love to commit and hit 5.x and 6.x-1.x with the pathauto fix - which I think may need priority at this point. If others can check this patch and comment/critique, however -- that would be awesome and most appreciated.
[edit] In terms of testing, it would also be great for Mark Carver's variable / namespace cleanup patch (#8 above) to get some testing. If we could really do all of this without introducing new issues, that would be awesome. Other committers and interested parties have comments/thoughts?
Also - as I know this is adding to timelines, I'm going to move my next efforts to committing a 6.x-2.x dev with #883604: Fully supporting and integrating PathAuto and Token and then focus on a 1.x branch patch for the same issue so people can test that as well. [/edit]
#18
I put Mark's #8 patch on a clean 2.x-dev install and didn't encounter anything unexpected. I went through all the changes and can verify that there are no variable stragglers left behind. The only thing I noticed was on line 207 of the patch (line 906 of the patched nodehierarchy.module): #delta is counting $child_links but the array hasn't been set. I think it is suppose to be $children_links. I don't have access to any complex sites to try the patch with, but I'm pretty confident it'll pass without any problems. I should be give that a shot tomorrow.
As for the recursive pathauto stuff, the nodeapi portion of the patch should work without any issues. The code is almost directly from the separate recursive pathauto module I've had on GitHub. That code has been working on a couple of production sites I have without any problems (or, at least, no problems have been reported back!). The brand spankin' new code in that is the integration with the menu pages, which hadn't crossed my radar until djac brought it up. Most of the code there utilizes the same nodeapi function, but there is some overhead from dealing with the menu. If it's problematic, I could certainly see separating out the newer menu code and aiming to get that integrated after some commits have happened. Oh, thanks for cleaning it up, too :)
I'm fairly hopeful that we can get all of these in without causing many issues. At the very least, it seems a reasonable approach to push them to a release candidate like Marc suggested in #6.
#19
I finally released a 2.0 stable. I did not include any additional functionality beyond the pathauto compatibility so we can now work on getting changes into the 2.1 release. Some of the larger interface and functionality initiatives can be broken off into branches (yay git!) so we can hopefully get bug fixes up in a more timely manner going forward.
Thanks everybody for helping shepherd this forward and my apologies for being such a negligent maintainer (I'll try to do better from now on).
#20
Ronan, you rock :) Thank you!
#21
Gratz guys
#22
I noticed that nodehierarchy 6.x-2.0 is not the recommended release for Drupal 6—6.x-1.4 still holds that position on the project page. Is this intentional?