Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
3 tasks
sbillinge opened this issue Dec 30, 2024 · 4 comments
Open
3 tasks

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

sbillinge opened this issue Dec 30, 2024 · 4 comments
Assignees

Comments

@sbillinge
Copy link
Contributor

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.

@sbillinge sbillinge added this to the 3.6.0 release milestone Dec 30, 2024
@sbillinge sbillinge changed the title develop a roll-out plan for the release release: develop a roll-out plan for the release Dec 30, 2024
@bobleesj
Copy link
Contributor

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

@sbillinge
Copy link
Contributor Author

@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?

@bobleesj
Copy link
Contributor

bobleesj commented Dec 31, 2024

(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?

@sbillinge
Copy link
Contributor Author

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants