FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

release: develop a roll-out plan for the release · Issue #295 · diffpy/diffpy.utils · GitHub

Repository navigation

release: develop a roll-out plan for the release #295

Open

Description

Problem

WE know how to push the release all the way up to conda-forge, but we want to have a series of steps we will take to advertise the new release and share it with the community

Proposed solution

  • Draft an email to send to diffpy-users
  • Post that message
  • Think of any other ways we want to share

We are looking for early-adopters/testers for the new functionality.

Activity

  1. added this to the 3.6.0 release milestone on Dec 30, 2024
  2. changed the title [-]develop a roll-out plan for the release[/-] [+]release: develop a roll-out plan for the release[/+] on Dec 30, 2024
  3. bobleesj commented on Dec 30, 2024

    Contributor

    I will also document this step by step process so that we can apply to all other packages ex) pdfgui etc

  4. sbillinge commented on Dec 31, 2024

    ContributorAuthor

    @bobleesj I started going through the diffpy.org website and marking up the pages on paper (actually using my new epaper device! haha!) I will be on a train tomorrow and can work on that and then we can just push out the edits. the more we can say simple things that don't have to be updated at each release, but point to super-clear docs elsewhere that deal with the details, the better. I think it is ok for the update of the diffpy docs to be after the release as we don't want to roll something out until we have used and tested it a bit. We proabably need 3 release dates for each release.... 1) finish the code and get it merged and make a pre-release (2) full release (3) roll-out after soft testing the full release, with these apart by a month or so?

  5. bobleesj commented on Dec 31, 2024

    Contributor

    (actually using my new epaper device! haha!)

    Nice! Indeed it's great for marking online docs.

    simple things that don't have to be updated at each release, but point to super-clear docs elsewhere that deal with the details, the better.

    Yes, I agree. The need for maintenance is not only effortful but also a source of failure, often.

    3 release dates for each release....

    (1) finish the code and get it merged and make a pre-release -> Dec 31, 2025 works
    -> Today Dec 31, 2024

    (2) full release
    -> Next 1-3 days depending on (1) and @yucongalicechen's schedule

    (3) roll-out after soft testing the full release, with these apart by a month or so?
    -> Maybe we could discuss this in-person in Spring 2025 (3rd week of Jan)?

    Between (2) and (3), should we announce in the group internally for testing?

  6. sbillinge commented on Dec 31, 2024

    ContributorAuthor

    Between (2) and (3), should we announce in the group internally for testing?

    yes....group and "friendly users" should be approached.

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

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


    Back | FazBrowse Home | New Git URL