Skip to content

Document versioning policy #9

Description

@mfisher87

Hey y'all, how do you think we should version this?

  1. Parity with JupyterGIS -- we may see breakages specific to this codebase, and would need to patch without getting out of sync with JGIS, which would require an extra version segment, e.g. 0.16.0.{N}.
  2. Its own version number and specify which JupyterGIS versions its compatible with by its dependencies on conda-forge

I personally think option (1) is better (this is very tightly coupled with the upstream API, I think it will be simpler for maintainers to only need to worry about a single JGIS version to be compatible with, and I think it will be simpler for users to be able to see at a glance what JGIS version the R API is compatible with -- downside, we'd need to release new versions of this API for upstream patches even if nothing changes in this API), but I'd love to hear arguments for alternatives.

I'd like to consider this resolved once we've documented our decision somewhere prominent.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationquestionFurther information is requested

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions