Version 2

[chambo-e]

Hello,
Is v2 still supported ?
Are recent fixes on master planned to be ported to v2 ?

[flowchartsman]

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

[robfig]

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...

[robfig]

@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.

[elgs]

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.

[dmitshur]

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.

[yuzhichang]

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).

[jgillich]

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

[ranjib]

@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.

[davisford]

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?

[oklahomer]

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.

[davisford]

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.

[JalfResi]

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

[basilex]

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?

[cooppor]

@robfig please give us a v2 release.

[robfig]

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