Redesign for v2

[JohnRoesler]

There have been plenty of issues for folks with the ability to get bitten by the current designs "chains" which don't clearly state the order in which each method must be called and errors can happen when called out of order. Currently the methods to set job related scheduling are done on the scheduler itself and therefore the scheduler has to set a job into the current context, apply the scheduling to that job and then save it into the scheduler.

To simplify that, I was thinking of changing the contracts so that all job specific scheduling was set on the job itself. Then that job could be passed into one or frankly many schedulers. Jobs would be resilient to having methods called in any order. What this could look like:

scheduler := gocron.NewScheduler(time.UTC)

job1 := NewJob().SingletonMode().StartAt(time.Now() + (5 * time.Minute)).Every("10m")

scheduler.AddJob(job1)

job2 := job1
job3 := job1

# add multiple at once, for example
scheduler.AddJobs(job2, job3)

# jobs could be set in a for loops where each loop sets a single scheduling
# parameter via method call depending on some logic the user has defined

myJobs := []*Job{job1, job2, ...}

for _, job := range myJobs {
    if ... { # logic user defines whether the jobs start now or not
        job.StartAt(time.Now())
    } else {
        job.StartAt(time.Now() + time.Hour)
    }
}

@Streppel @arjunmahishi

[arjunmahishi]

Looks pretty clean. What would be the role of the scheduler though? In the above scheme, it looks like the scheduler is just a group of jobs (if I'm not wrong). In which case, it could be renamed Runner or something along that line.

Although, I kind of liked the idea of "scheduling" being decoupled from the "job" itself. But 👆🏽 this looks more intuitive from a user point of.

[JohnRoesler]

perhaps we could redo our terminology. In this case then,

scheduler -> a logical grouping of job schedules
job -> scheduled job
jobFunction -> is the actual "job" that will be executed