Skip to content

Communicating our versioning policy better #10837

Closed
typeshed-internal/stub_uploader
#114

Description

@srittau

#10825 made it clear that we need to communicate our versioning policy better. The first step is to add a note about it to package descriptions as suggested by me in typeshed-internal/stub_uploader#104. But I think we could also communicate the "specialness" of the typeshed part of the version number better. A few ideas:

  • Don't reset the version number when the upstream version changes.
  • Start with a high number, e.g. 1000 to make it stand out, e.g. 1.2.3.1023
  • Use the current date (and limit to one upload per day): 1.2.3.231005
  • Bump the version significantly on major changes, e.g. 1.2.3.1023 -> 1.2.3.2000
  • Edit: Use epochs, e.g. 45!1.2.3

Personally, I think options 1 and 2 combined would be a good solution, although I find option 3 strangely appealing as well.

Activity

  1. srittau commented on Oct 12, 2023

    @srittau
    CollaboratorAuthor

    I'd like to bump this again. I still think we should at least bump the minimum stub version up to 1000 to signify that it's "special", although I really like the idea to use the current date. A version like 1.2.3.231012 looks weird, but it really stands out. Any opinions?

  2. Akuli commented on Oct 12, 2023

    @Akuli
    Collaborator

    I like the date versioning (aka calver) idea, and I think it would be a good fit for typeshed.

    Maybe we should use full years in the version number, as in 1.2.3.20231012? The meaning is more obvious, and I don't really see any downsides in this.

  3. AlexWaygood commented on Oct 12, 2023

    @AlexWaygood
    Member

    Thanks for bumping @srittau! Agree that our current policy looks too much like we're just making a "micro version bump", which isn't really how we do things here.

    I basically agree with @Akuli -- I also quite like the date versioning idea!

  4. srittau commented on Oct 12, 2023

    @srittau
    CollaboratorAuthor

    We also don't need to limit the uploads. Just use the next free date if the current date is already in use. I don't think it's a problem if a package is a day in the future from time to time.

  5. Akuli commented on Oct 12, 2023

    @Akuli
    Collaborator

    IMO it would be better to limit the uploads. Suppose a contributor is doing large manual changes into a specific package, and makes 5 pull requests with 3 hours between each PR (total time spent would be 12 hours, so not unreasonable). If we merge the PRs quickly, this would get stub-uploader 4 days ahead in one day.

  6. AlexWaygood commented on Oct 12, 2023

    @AlexWaygood
    Member

    I agree with @Akuli. I also think limiting uploads of any one stubs package to once per day is fine. That's already a much more frequent release schedule than you'll get with basically any other open-source package.

  7. added a commit that references this issue on Nov 2, 2023
    551b2b9
  8. srittau commented on Nov 21, 2023

    @srittau
    CollaboratorAuthor
  9. srittau commented on Dec 20, 2023

    @srittau
    CollaboratorAuthor

    And it worked (ignoring the integration test failures): https://pypi.org/project/types-networkx/3.1.0.20231220/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    project: policyOrganization of the typeshed project

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions