I think rather than have a bunch of scripts, one per task, we could have a single one that takes commands and does stuff based on the command.
In this spirit, I’ve created dev-tools/scripts/manageRelease.py, which only does one thing right now: makes regexes for all JIRAs included in a release by parsing the CHANGES.txt files. (This is to simplify the task of figuring out which JIRAs in a release are duplicated in CHANGES.txt under previously unreleased versions - with a regex, you can do a search/match-all in a regex-aware editor and very quickly find matching JIRAs under other releases.) The script will need work to accept commands to do other things, though: I didn’t put anything in place to do the command-switching thing. If we don’t want to go this way, we can rename manageRelease.py to releasedJiraRegexes.py or something. -- Steve www.lucidworks.com > On Jun 1, 2016, at 2:36 PM, Chris Hostetter <[email protected]> wrote: > > > : 1. I think if used this will become the de facto source of RM > : documentation, so it will have to be able to do a full listing of all > : steps, maybe also the steps that *aren’t* included too for the given > : release type, so that the RM can see/verify the full context. > > wouldn't that just be a matter of reading the "original" JSON that's > commited into dev-tools (ie: not hte copy currently being worked through) > > : 2. The JSON file shouldn’t be stored in the source tree; several steps > : look for/assure clean checkouts. Maybe a configurable location with a > : default uner /tmp/releases/X.Y.Z/ (already used by at least one release > : script now). > > ok, sure ... i was suggesting it could be explicitly .gitignored, but i'm > not hung up on the details. > > : 3. Some things can be safely done out of order, while others have > : prerequisites. Maybe the script could somehow make these dependencies > : visible? Skipping and out of order completion (and progress for some > : manual multi-step things) should be supported as well. > > sure ... again: these seem like minor details to the boarder goal of > "script everything, including the checklist" > > If this is a goal folks think make sense, then frankly scripting the > checklist itself seems like it should be something we worry about waaaay > down the road. > > Starting with "add more scripts that echo the exact commands to > copy/paste based on the version# + RC# of the release" seems like where > the first big wins could come from... > > Examples: > > updateVersionNumbersOnAllAffectedBranches.py 6.2.0 ~/lucene/my-checkout > 1. looks at the list of branches/tags in ~/lucene/my-checkout > 2. echos the exact list of "git co", "addVersion.py", > and "git commit" commands you should run based on 6.2.0 being > a minor release > 3. warns you if any expected backcompat indexes are missing on > any branches > 4. echos the "git push origin ..." command listing all affected > branches > 5. if you run it again, after running some of the commands, > only echos the commands that are still needed > > tagAndPublish.py lucene-solr-6.2.0-RC2 DEADBEEF > 1. echos the exact tag command to run > 2. echos the exact svm mv && svn rm commands for the dist repo > - including rm'ing RC0 and RC1 if they still exist > 3. echos the exact ant commands to publish to maven > 4. echos the instructions/url to close & release on maven central > 5. echos the "git push origin ..." command for the tag > 6. if you run it again, after running some of the commands, > checks that the tag matches DEADBEEF, and only echos the commands > that are still needed > > etc... > > > > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
