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.
@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?
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?
Activity
bobleesj commented on Dec 30, 2024
I will also document this step by step process so that we can apply to all other packages ex) pdfgui etc
sbillinge commented on Dec 31, 2024
@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 commented on Dec 31, 2024
Nice! Indeed it's great for marking online docs.
Yes, I agree. The need for maintenance is not only effortful but also a source of failure, often.
(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 commented on Dec 31, 2024
yes....group and "friendly users" should be approached.