Version 2 about cron HOT 15 CLOSED

You're absolutely right. It's hard to maintain two separate branches. Maybe I should just port the changes from v2 back to master and assume that people use pinned versions or vendoring for anything serious...

from cron.

I myself don't mind breaking the compatibilities. The only thing I need is when a job is created, I need a handle/reference to that job so that at a later time, I can use that handle/reference to do something to that job, mostly stop it and remove it.

from cron.

I didn't know v2 even existed.

If it were up to me, I would do it. Those who care about backwards compatibility and things not breaking unexpectedly will be vendoring this library anyway, so they won't be negatively affected (and if they're not vendoring and feel unhappy, they should be vendoring).

For everyone else, they'll get exposed to the latest and most optimal library API by default. And it's less effort and maintenance for you.

Those are my generic thoughts. I haven't looked at the differences in the API, so I can't comment on that.

from cron.

There is now a v3 branch which works with Go Modules, which has all the fixes and updates from both master and v2 branch.

I'm still tracking down a couple last bugs and one more upgrade in functionality before calling it done. Feedback is welcome. Thanks

from cron.

+1, also regular tagged releases would be awesome, glide default to v1 from 2014

from cron.

Have to agree - been waiting to start a little project of mine, thought I'd wait until delete jobs was merged in from v2. Backwards compatibility could be sacrificed if using semantic versioning (its looking like the official vendor functionality will support this in future).

I think there are enough new features and stability fixes as to make breaking compatibility worthwhile to existing users IMHO

from cron.

Yes, it would be nice not to have to go to a fork or alternate branch for remove functionality.

from cron.

@elgs @shurcooL as frequent contributors, what is your opinion on porting v2 to master and breaking backwards compatibility? Is that worth it for the simplification, or would it just break a ton of users? Right now v2 is invisible and not helping folks as much as it could, and it's a pain to maintain separate versions.

from cron.

master is more active than v2, and has some important fix. Hard to tell which branch is better.
I agree with shurcool. I would suggest make v1 a release branch (only important bug fix), and make master as the developing branch(new feature + all bug fix).

from cron.

@robfig do you need any help with porting the v2 stuff on master? I need the remove job feature from v2 but dont want to use non-master branch for a brand new project. I can help with porting bits & pieces. Its gonna break the existing users, but I think thats fair.

from cron.

Hi @robfig just chiming in -- I'd like to be able to remove a job (in v2 only), but I also need support for Location -- since testing is damn near impossible for other time zones without being able to run it in a fixed time.Location. Is there another branch that supports both of these features somewhere?

from cron.

Does this work help?
I also wanted the ability to remove registered schedule so I forked @robfig's original repository, created new branch from latest master (9585fd5), and applied most of 2b666ea.

If this helps most of you guys and reasonably comply with what @elgs and @shurcooL expressed, I'd create a pull request so that my change can be part of robfig's original repo and be maintained.

Below are what I did in my repo:

• Forked and created topic branch based on 9585fd5.
• Applied most of 2b666ea. Since this focused on removing jobs, some are not applied.
  • The changes to entrySnapshot's interface and related parts are not included.
  • The ability to retrieve Entry by ID and to check the validity of returned Entry are not included.
• Tests are also ported with a bit of additions, and the result is available at travis ci.
  • I did not change link to travis ci on README.mkdn so be careful. Clicking on that link still leads to the result page of original repo.
• Checked v2's later commits than 2b666ea to see if any relevant change is missing.

Lastly I appreciate @robfig for creating this package. I especially like how cron.Parse works.

from cron.

Thanks @oklahomer -- also very much appreciate @robfig's work here. It looks like a solid little utility. I ended up browsing the fork network and grabbed this derivation as it included the removal, as well as time.Location and added support for named jobs, which is desired for me. Don't want to see this repo splintered, but as always...have to move fast. Thanks.

from cron.

Would be nice to have an additional interface cron methods like Suspend and Resume by EntryID.
Currently I need to save credentials of running job, remove it, and add it again with another Schedule...
Any ideas?

from cron.

@robfig please give us a v2 release.

from cron.