Hi, The error message is perhaps not too helpful for how to proceed.
I believe you have initialized the wizard already for a bugfix release. See $HOME/.solrrc if there is a version set already. Then it will complain since it believes you are to release a bugfix from stable branch. You can re-initialize the wizard with dev-tools/scripts/releaseWizard.py --init Hope that helps. The error message should probably mention that release x.y.z is already in progress and the --init option. Jan > 22. apr. 2024 kl. 15:28 skrev Gus Heck <gus.h...@gmail.com>: > > Except it quit with an error complaining about the version before the > checkout step in the menus (or any menus)... so it does look at the local > checkout for that... > > On Mon, Apr 22, 2024 at 9:11 AM Jan Høydahl <jan....@cominvent.com> wrote: > >> You don't need to run the wizard from a pristine checkout, or even from >> the clone in .solr-releases/ >> The only requirement is that you run the wizard from some recent enough >> checkout of the correct branch. >> The wizard will not use the "current" git repo for anything else than for >> reading releaseWizard.py and releaseWizard.yaml. >> The actual release will always be a fresh clone in .solr-releases/ >> >> So if you quit for the day and want to resume the release tomorrow, you >> just go to some Solr checkout, do a git checkout branch_9x, and then run >> the wizard. >> If you need to do bug fixes to the wizard itself during the release, you >> can do so in your own clone, and then make a PR for any wizard fixes after >> the release is done. >> Fixes to the wizard itself is most often put in main then back-ported to >> stable branch. Then if a RM is to do a bugfix release she should first >> consider whether the wizard is up to date on that branch. >> >> Likewise, if you do a major release, you'll run the wizard from "main" >> branch. If you do a bugfix release 9.5.x then you'll run the wizard from >> branch_9_5. >> >> I'm sure there was some reason for this design back then. I think the >> reason was that the wizard code and steps could actually differ between >> versions, since e.g. main branch may include new features that demand >> special treatment during release. One such is the JDK version requirement >> that is checked at start. I'm sure you'll find others by diffing wizard >> between branches. >> >> Jan >> >> >>> 22. apr. 2024 kl. 14:03 skrev Gus Heck <gus.h...@gmail.com>: >>> >>> Will definitely follow this release with some documentation of what you >>> just told and other basic "orientation". For example it refers to a >> "root" >>> folder but exactly what it intends for that folder is opaque until much >>> later in the process (place for code? place for artifacts? root of what?) >>> ... you have now told me but there's still some disconnect because if >> it's >>> creating such a root, prior to checkout how am I supposed to have the >>> wizard to run in the first place if I haven't checked it out already... >> so >>> there's unclarity on "run it from a X and it does work in Y perspective. >>> (or alternately perhaps it's intended to run it to point Z and then, stop >>> and, re-run it in the checkout?)" >>> >>> Having run it from within a pristine checkout of my own, it then would >> not >>> even get to the menus unless I commented out the highlighted line... And >> it >>> runs a bunch of checks and won't even get to the menus unless you fix >> those >>> prerequisites ... and then later one of the menu items tells you to >> verify >>> the same items. >>> >>> -Gus >>> >>> On Mon, Apr 22, 2024 at 5:30 AM Jan Høydahl <jan....@cominvent.com> >> wrote: >>> >>>> Hi Gus >>>> >>>> Could be documentation is weak, but the assumption is that for a minor >>>> release you run the wizard from branch_9x. >>>> >>>> The wizard will not run commands unless you ask it to, but it will >>>> generate the command, print it, and once you accept it will be run. If >> you >>>> prefer for som reason to run a certain command manually you may do so, >> and >>>> when the script asks whether a step is done, you answer Y. >>>> >>>> The script persists a FILE .solrrc on first run (whether dry or no), >> which >>>> will remember which folder you use for releases (default >> ~/.solr-releases). >>>> >>>> If you started the release and branch cutting outside of the Wizard, you >>>> should still be able to catch up by starting the wizard, and completing >>>> each step until you come to the branch cutting part, where you simply >> skip >>>> that command since it is already done. Note that the wizard performs all >>>> operations on a pristine git clone inside .solr-releases, so you may >> have >>>> to run a git fetch on that clone. >>>> >>>> Feel free to ask for other questions. There are many former RMs here. >> And >>>> also appreciated with PRs for the wizard itself should ther be bugs or >>>> unclear documentation. >>>> >>>> Jan >>>> >>>>> 21. apr. 2024 kl. 22:08 skrev Gus Heck <gus.h...@gmail.com>: >>>>> >>>>> Also I just realized that despite --dry-run it seems to have written a >>>>> .solrrc file in my home dir (it did not write it in ~/.solr-releases >> that >>>>> it suggested as a root?) >>>>> >>>>> it seems unexpected for --dry-run to leave persistent changes? >>>>> >>>>> On Sun, Apr 21, 2024 at 3:37 PM Gus Heck <gus.h...@gmail.com> wrote: >>>>> >>>>>> I had initiated dry runs a few times earlier this week and it stopped >> on >>>>>> various dependencies, and I've not got those checks happy, but now I'm >>>>>> getting: >>>>>> >>>>>> "You can only release bugfix releases from an existing release branch" >>>>>> >>>>>> The logic I see in the code doesn't make any sense... >>>>>> >>>>>> def validate_release_version(self, branch_type, branch, >>>>>> release_version): >>>>>> ver = Version.parse(release_version) >>>>>> # print("release_version=%s, ver=%s" % (release_version, ver)) >>>>>> if branch_type == BranchType.release: >>>>>> if not branch.startswith('branch_'): >>>>>> sys.exit("Incompatible branch and branch_type") >>>>>> >>>>>> * if not ver.is_bugfix_release(): sys.exit("You can >> only >>>>>> release bugfix releases from an existing release branch")* >>>>>> elif branch_type == BranchType.stable: >>>>>> if not branch.startswith('branch_') and >> branch.endswith('x'): >>>>>> sys.exit("Incompatible branch and branch_type") >>>>>> if not ver.is_minor_release(): >>>>>> sys.exit("You can only release minor releases from an >>>>>> existing stable branch") >>>>>> elif branch_type == BranchType.unstable: >>>>>> if not branch == 'main': >>>>>> sys.exit("Incompatible branch and branch_type") >>>>>> if not ver.is_major_release(): >>>>>> sys.exit("You can only release a new major version from >>>>>> main branch") >>>>>> if not getScriptVersion() == release_version: >>>>>> print("WARNING: Expected release version %s when on branch >>>> %s, >>>>>> but got %s" % ( >>>>>> getScriptVersion(), branch, release_version)) >>>>>> >>>>>> It seems to be looking for something other than a X.Y.0 in order to >> do a >>>>>> release that is not a bugfix release (is_bugfix_release checks that >> the >>>>>> final digit is other than 0 )? but x.y.0 is correct for a non bugfix >>>>>> release? >>>>>> >>>>>> In any case this seems to be 100% blocking and I'll need to comment it >>>>>> out... but I worry that there's some undocumented assumption that this >>>>>> script has to be run before the branch is made and it's unclear what >>>> it's >>>>>> going to try to do if the branch exists. Is it expecting to run its >> own >>>> VCS >>>>>> commands? (I think it really should be suggesting commands that touch >>>> the >>>>>> repo for human review, not running them if that's the case) >>>>>> >>>>>> My first initial comment on this process is scripts are nice, but if >>>> they >>>>>> are black boxes and there's no documentation of the intended process >> or >>>>>> where the script comes into the process and what parts of the process >>>> the >>>>>> script is handling, it's pretty hard to know how to use the script (or >>>> how >>>>>> to know if it goes awry) >>>>>> >>>>>> -Gus >>>>>> >>>>>> -- >>>>>> http://www.needhamsoftware.com (work) >>>>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >>>>>> >>>>> >>>>> >>>>> -- >>>>> http://www.needhamsoftware.com (work) >>>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>> >>>> >>> >>> -- >>> http://www.needhamsoftware.com (work) >>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> >> > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book)