-
Notifications
You must be signed in to change notification settings - Fork 4
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
2020.4 #342
Conversation
Update agasc to 4.8.1 Update acisfp_check to 3.0.0 Update acis_thermal_check to 3.0.0 Update backstop_history to 1.1.3 Update chandra_aca to 4.29.1 Update dea_check to 3.0.0 Update dpa_check to 3.0.0 Update parse_cm to 3.5.2 Update proseco to 4.8.0 Update psmc_check to 3.0.0 Update pyyaks to 4.4.2 Update Quaternion to 3.5.2 Update sparkles to 4.6.0 Update xija to 4.17.1 Updated and an empty message aborts the commit.
Looks good. I made a new releaes for mica that should be good to go. |
So PR got expanded from "just the ones we really need" to "everything except the namespace packages". That adds a file like parse_cm and pyyaks. I'm good with that and seems straightforward and appropriate. |
Well, I'm fine either way. I can remove the updates to pyyaks, parse_cm, agasc and backstop_history, which are not relevant or windows-related. Perhaps also annie. |
Also fine either way. The content for briefing is tiny for each. |
Also, what's the magic again to get the PR list* that you're now using? I assume it isn't quite automated for this kind PR but not sure if that changed (and it is automated) or if it is a process in the skare3_tools or wiki. *awesome |
Right now the list comes from a script I have not checked in. It is based on a script in skare3_tools/scripts/skare3_update_summary. My local version can compare between two sets of versions. The list of issues that say "Fixes #..." is another script that is also not checked in. It's a little function that takes the milestone and prints out all skare3 issues labeled "Package update" for that milestone. |
pkg_defs/ska3-flight/meta.yaml
Outdated
@@ -1,6 +1,6 @@ | |||
package: | |||
name: ska3-flight | |||
version: 2020.02.12 | |||
version: 2020.04.24 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forget if there was some agreement or reasoning otherwise, but I thought this should just be 2020.4. That makes the version here match the release tag and the milestone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In other words, starting in 2020 all the version tags will be YYYY.N where N just increases by 1 for each release. This can include skipped releases. That would include the others like ska3-template or ska3-core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My disagreement was that when these were candidates I lost my ability to make packages with unique names as we went through updates. For example, in this PRI already would have incremented to 04.25 after the mica fix because knowing me I'd have built 04.24 without mica and would have that actual packagehanging around to confuse me (or my auto package building wouldn't have actually rebuilt ska3-flight after adding mica because 04.24 already existed).
I don't really care if we move forward with some of @javier's ideas for SCM of the meta.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind either way. I also thought that it would be 2020.4, but in 2020.3 I saw Jean was still following the date format and that got me thinking that releases can be 2020.n until the actual final tag, and then they get their final "date" name. But that was just me thinking, I agree.
So... no problem in changing it to 2020.4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have certainly experienced the pain of "over-caching" by conda and getting confused. So we might consider using a standard versioning convention like 2020.4rc<N>
until the last one. I can't tell if the pain of that is greater than the pain of remembering to clear caches or force-build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, the Python standard https://www.python.org/dev/peps/pep-0440/#pre-releases does not include a dash before the rc
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had wondered if it would be less work in the end to just manage ska3-flight and ska3-core as two new very small git repos but I think @javierggt has better ideas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also talked about maybe just combining ska3-core into ska3-flight but I have enjoyed having noarch updates possible for ska3-flight (though that could all be moot with real multiplatform auto builds).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I have in mind at this time is the following:
- One releases one meta-package at a time, so ska3-core would have to be released before ska3-flight. Each ska3-flight corresponds to one and only one ska3-core. There is no issue.
- When you make a release (or just a tag) an action is triggered. This action reads meta.yaml and overwrites the version of the package to create a conda package which is uploaded to a repository. This is the same as with other packages, except the name of the package to build comes from the tag (not the repository name).
- this package eventually winds its way to the test conda channel (instead of masters).
- when a new ska3-flight package appears in the test conda channel, that triggers a testr run.
- eventually the results from this run make it to the dashboard (steps omitted here).
- Once we agree on a final yaml config, we tag/release again, without the rc#. The process repeats, and the package ends up wherever we want it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not quite sure if we can promote ska3-core updates independent of ska3-flight, but we could probably release in that order? Not sure where to capture this discussion but should probably resolve the conversation for this line of the meta.yaml :-)
I'll change my review to approved when #321 gets merged. |
The 2020.4 release includes:
These substantive updates and a few others are also called out in bold in the full list of changes below.
New Packages
aca_view 0.3.0
bep_pcb_check 3.0.0
fep1_actel_check 3.0.0
fep1_actel_check 3.0.0
Changes
acis_thermal_check: 2.9.2 -> 3.0.0 (2.9.2 -> 2.9.3 -> 3.0.0)
acisfp_check: 2.7.2 -> 3.0.0 (2.7.2 -> 2.7.3 -> 3.0.0)
backstop_history: 1.1.2 -> 1.1.3 (1.1.2 -> 1.1.3)
dea_check: 2.3.2 -> 3.0.0 (2.3.2 -> 2.3.3 -> 3.0.0)
dpa_check: 2.5.2 -> 3.0.0 (2.5.2 -> 2.5.3 -> 3.0.0)
psmc_check: 1.3.1 -> 3.0.0 (1.3.1 -> 1.3.2 -> 3.0.0)
acdc: 4.4.1 -> 4.5.0 (4.4.1 -> 4.5.0)
agasc: 4.8.0 -> 4.8.1 (4.8.0 -> 4.8.1)
annie: 0.9.1 -> 0.10.1 (0.9.1 -> 0.10.0 -> 0.10.1)
chandra_aca: 4.28.1 -> 4.29.1 (4.28.1 -> 4.29.0 -> 4.29.1)
mica: 4.20.0 -> 4.21.0 (4.20.0 -> 4.21.0)
parse_cm: 3.5.1 -> 3.5.2 (3.5.1 -> 3.5.2)
proseco: 4.7.2 -> 4.8.0 (4.7.2 -> 4.8.0)
pyyaks: 4.4.1 -> 4.4.2 (4.4.1 -> 4.4.2)
quaternion: 3.5.1 -> 3.5.2 (3.5.1 -> 3.5.2)
sparkles: 4.4.0 -> 4.6.0 (4.4.0 -> 4.5.0 -> 4.6.0)
xija: 4.16.0 -> 4.18.2 (4.16.0 -> 4.17.0 -> 4.17.1 -> 4.18.0 -> 4.18.1 -> 4.18.2)
Testing status
We note two test failures that we consider non-issues for this release:
Checklist
Fixes Issues
Fixes #325
Fixes #318
Fixes #331
Fixes #336
Fixes #335
Fixes #334
Fixes #337
Fixes #324
Fixes #319
Fixes #316
Fixes #327
Fixes #328
Fixes #330
Fixes #339
Fixes #313