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)
