LMK what you think of https://issues.apache.org/jira/browse/SOLR-17244
(more legible than the PR is my branch :
https://github.com/gus-asf/solr/blob/SOLR-17244/dev-docs/releasing.adoc)
On Mon, Apr 22, 2024 at 4:36 PM Jan Høydahl <jan....@cominvent.com> wrote:
> 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)
>
>
--
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)
