lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Rowe <sar...@gmail.com>
Subject Re: [DISCUSS] Lucene/Solr release management
Date Mon, 27 Jun 2016 20:19:07 GMT
So I changed my mind: I think calling the script manageRelease.py was premature, since it only
did the one thing, so I’ve renamed it to releasedJirasRegex.py and cleaned it up a bit.

If we decide to go the central script route, we can add manageRelease.py then.  That script
will likely just call out to other (standalone) scripts; it probably won’t hold any task
implementations.

--
Steve
www.lucidworks.com

> On Jun 24, 2016, at 7:56 PM, Steve Rowe <sarowe@gmail.com> wrote:
> 
> 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 <hossman_lucene@fucit.org> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message