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)
