Hi. I notice the latest recommend release is over a year old and yet a lot of us are using dev branches due to some of the patches/fixes along the way.

Any chance we can get a 7.x-1.1 release cut so we can stay on a recommended release for a while and not get notifications from drush to keep updating? Not a complaint, just a suggestion...

My clients love this module, BTW :)

CommentFileSizeAuthor
#16 scheduler.zip16.39 KBAlan D.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Alan D.’s picture

Second this, it has been two years without a release.

I didn't spend the time to see the diff between 7.x-1.x-dev and 7.x-1.0, but I guess there are no critical issues as there are only 100 users of 7.x-1.x-dev c/f 19,000 of 7.x-1.0

rickmanelius’s picture

It looks like we may have to submit a request to take over as co-maintainer. The last commit to this project was over a year ago.

rickmanelius’s picture

Quick followup: Dealing with unsupported (abandoned) projects -> (http://drupal.org/node/251466)

jonathan1055’s picture

Hi AlanD and rickmanelius,

Yes, I do not know what has happened to Eric (http://drupal.org/user/20786) the current maintainer. He has not posted here for ages. I have contributed, and will continue to contribute, patches enhancements and support, but I am not in a position to take on co-maintainership. If you both would like to, that would be great news.

The module is well-liked and used by many sites. In fact at 20,000 the number of 7.x sites is rapidly approaching and going to soon overtake the number of 6.x sites 23,000, so we really should get a new release. There are also several patched fully tested and ready to be committed.

I hope you can take on co-maintainership. Eric is very good to work with, and I just hope we can contact him and help share the workload.

Jonathan

jonathan1055’s picture

Hi,
Good News! I have made contact with Eric and he would be pleased to have a co-maintainer (or even two). He is busy right now, but after Easter he'll be back here on the board and follow up then.

It will be great to have you back, Eric :-)

Jonathan

rickmanelius’s picture

I'd be happy to co-maintain. I use this module on several sites and would like to see any patches/fixes get put in place.

mengi’s picture

It would be great to get a new release since it is never fun having to use a dev version for production sites. Thank you for stepping up rickmanelius!

Eric-Alexander Schaefer’s picture

Hi Folks,

I just added Rick to the list of maintainers. Please go ahead and give scheduler a little love. I am afraid my schedule does not permit me to be involved any further at this time. This might change in a couple of weeks when I need to port two sites using scheduler to a newer drupal version... ;-)

Thank you Jonathan for keeping up support for scheduler. I appreciate it.

Regards,
Eric

rickmanelius’s picture

Hi Eric,

Thank you very much. I'll start the process of getting the RBTC queue cleaned up and get a 1.1 release in the near future.

-Rick

jonathan1055’s picture

Thank you Eric and Rick, this is really great news.
Jonathan

rickmanelius’s picture

Status: Active » Needs review

I've cleared most of the RBTC queue except for #1660192: Expand options for integrating modules, which should be straightforward once we get clarification.

It would be helpful if someone wanted to quickly scan the issue queue for any other major tickets that would be worthwhile of a 1.1 release and post them here. Otherwise, please review the current dev release and we'll have an official 1.1 release within a week or two. Thanks!

Alan D.’s picture

#1199908: Some missing translations - trivial manual patch to apply by hand. 4 loc that simply wrap some t() around non-translated strings.

Massive list of feature requests, that could take some time to go through but these shouldn't hold off a release.

BTW, don't close issues, rather mark them as fixed. These stay in the queues for 2 weeks and are then automatically closed by cron. This allows subscribed users to check & test etc

#1052628-5: Make sure node type specific configuration variables are removed for deleted/uninstalled node types

Nice to see some activity in the thread. This is a very useful module! :)

rickmanelius’s picture

Hi @Alan D. Understood re:setting the status to fixed. I'll be more careful in the future. Also, with respect t the trial patch, the only reason I mentioned it was because it looked like there could be some other form titles that could also be rolled in. However, yes, I could simply manually adjust them and call it a day :)

jonathan1055’s picture

Rick,
Thank you so much for taking this on and getting the patches committed. Your work is very much appreciated.

I will download the test the latest dev, and check all of the fixes. Other folks are welcome to do the same, too.

Jonathan

jonathan1055’s picture

Hello again,

I've just downloaded the dev dated 16th April, but I can only detect one change - the one from #1358656: Incorrect link to settings in cron dblog. The other three commits have not appeared in the code (or they have been replaced with the old version, or overwritten).

I can see that you have committed the patches, eg http://drupalcode.org/project/scheduler.git/commitdiff/86ce2ff. Is there a delay in when these should show up in the dev version that is displayed for download on the project page?

Jonathan

Alan D.’s picture

FileSize
16.39 KB

yep, up to 24 hours. Use the version tab to check this out or use the attached zip (will be out of date as of the next commit). Extract the zip to the folder scheduler (done this way to avoid zipping the .git folder)

jonathan1055’s picture

Thanks Alan. I've just downloaded the latest and it has all the changes. Looking at the .info file, the version is version = "7.x-1.0+11-dev" whereas this morning (with one commit) was version = "7.x-1.0+8-dev"

The datestamp value has increased, so it would have been useful if the .info file showed the date and time, not just the date. Maybe that's a feature request for D8.

Jonathan

rickmanelius’s picture

Aright... I'll cut a 1.1 when the following are committed.

#1199908: Some missing translations
#1660192: Expand options for integrating modules

I'll then do another batch of RBTC reviews for 1.2 and so on.

Thanks everyone!

rickmanelius’s picture

Status: Needs review » Fixed

Hi Everyone. I just cut a 7.x-1.1 tag. http://drupalcode.org/project/scheduler.git/commit/557611ca1bd0770084eab...

I just wanted to say thanks @Eric Schaefer for allowing me to be a co-maintainer. I also wanted to say thanks to everyone for all their help. This is my first time in this role and I appreciated all the helpful tips and feedback.

Alan D.’s picture

Nice work, there is always a bit of a learning curve with things!

Check with the core maintainers, but one thing many module do is to use the author tag in the commit to credit the patch writer directly for the commit. Git keeps a history of who pushed and the accredited author. When doing this, the commit shows on that users' page, so a complete newbie to drupal with no module rights can get a commit accredited to Views or similar. A very cool way to spawn community interest.

For example

Project: Empty Fields
Issue: #1822592: Breaks insertion of node fields in panel panes when field formatter settings not set by default (e.g. date_plain)
Patch provided by: setvik (http://drupal.org/user/77805)

I used this command for committing this trivial patch.

git commit --author="setvik " -m "Issue 1822592 by setvik: Prevent errors in empty_fields_field_formatter_info_alter() if settings is not set."

The --author="setvik " bit was taken from setvik user page on drupal.org. Afterwards his name shows up in the commit listings and the Empty Fields module was added to his user page on d.o

Btw, I am not suggesting that setvik is a newbie, just that this was only one of two examples located by "history | grep author" in my bash shell

rickmanelius’s picture

Hi @Alan D. Doh! I thought I was already taking that into account with the commit message. I'll make sure to do that in the future because I agree, it's nice to give credit where credit is due.

One more step along the learning curve :)

Alan D.’s picture

Normally, the bit "Issue # by [insert name(s) here]:" I use to credit everyone that has helped. Sometimes the reporter, patch writers for the final patch that was committed, anyone that gave help testing etc. If big, then I leave this with 2 or 3 user names that helped the most. I normally duplicate the commit author here, so when doing a change log, you can cut n paste the commit messages with everyone's name listed.

This is my way, I am not sure on the exact protocol more widely used. ;)

jonathan1055’s picture

A few of the recent commits could also be ported to D6. Maybe we need to have a discussion about what we are going to port back to D6?

Rick/Eric/Alan - do we need to open a new issue to discuss that topic?

Jonathan

rickmanelius’s picture

Hi @jonathan1055. I am open to the idea of backporting, but will likely spend most of my community time on bug fixes specifically for D7. That said, knowing how active you are in the threads, if D6 patches are provided to help speed up the process of back porting, I will certainly not ignore those efforts and get them committed :) What I would suggest though is focusing on bug fixes/maintenance tasks versus new features.

Alan D.’s picture

do we need to open a new issue

Personally I would change version if it is also a known issue in D6. That way you keep the thread history et al with the issue and often a backport is fairly trivial. Maybe 6 months to a 1 year before D8, which would then mean that D6 core is no longer supported, so is it worth it? Personally, this is only yes if you have to maintain a D6 version or two or more people do most of the work (patch and review) for you! ;)

jonathan1055’s picture

do we need to open a new issue?

Personally I would change version if it is also a known issue in D6. That way you keep the thread history et al with the issue and often a backport is fairly trivial.

Hi Alan, sorry maybe I wasn't clear, I did not mean opening a new issue for each fix we might port, I would definitely change the version in the existing thread. What I meant was to start a new issue for general discussion of what we should and should not port. But that is happening here now anyway, so I wont start a new thread.

My main customer is still on Drupal 6 and that is the site where I started using scheduler, so I would definitely like to see bug fixes ported back to 6.x. I can create patches for the ones I think should be ported.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.