Version numbering for next release

Hi All,

As part of an upcoming release I would like to release dask-jobqueue. What should the version number be? Some options:

1. 0.6.2 - this will be a minor version change in functionality
2. 1.0 - this library is fairly stable, might as well call it 1.0
3. 2.2 - let’s just match Dask version numbers going forward

What should we use?

[lesteve]

My preference would be 0.6.2. I feel the pace of development of dask/distributed is a lot quicker than dask-jobqueue and that keeping versions in sync does not make complete sense to me.

I have made some similar comment in https://github.com/dask/dask/issues/5168#issuecomment-516912659.

Something I have been thinking about in seeing the changes needed for distributed >= 2, and now distributed >= 2.2 (thanks a lot for this @mrocklin by the way!) is that dask-jobqueue is exposed to what feels like internal dask/distributed details.

My feeling is that one of the main reason is that at one point we decided to create dask_jobqueue.core.ClusterManager and our base cluster class JobQueueCluster is not inheriting from distributed.cluster.Cluster (see #187 for the PR and #170 for some of the motivations) . I think that we should revisit this decision. I may well be wrong about all the rest of this message because I have not had as much time as I wanted to look at this unfortunately … more than open to comments/complaints/corrections!

It would be great to have @guillaumeeb’s opinion on this because he was the main person involved in this IIRC.

I seem to remember there were two reasons for the dask_jobqueue.core.ClusterManager change:

• we wanted to do some dask-jobqueue specific experimentations, for example where the scheduler was on a different node than the main script or where the cluster object manages different kind of workers. As we are all quite busy with other things, it did not really happen as far as I know. Also some stuff has happened on the distributed front, e.g. the SpecCluster (although I have not followed very closely it seems like it could do the heterogeneous workers use case).
• we wanted to have different arguments for scale min_cores, min_memory. I don’t think that was one of the main reason. See #184 for the PR.

[guillaumeeb]

I think we can close this one for now, consensus was reached to keep independant ersion numbering.