I'm not sure a tag would add a whole lot of value, and would add a
little bit of clutter. I don't think splitting a rebase into two will
help very much (and if it is, the commit of interest just a few commits
before the soon to be created 2.1.0-rc1 tag). The hard part is knowing
how to deal with conflicts. Two rebases wont' minimize those all that much.
I've rebased this Apache patchset onto master many times and have gotten
really good with dealing with the conflicts. If anyone has any branches
that are pre-Apache switch, I'd be happy to help rebase those changes
onto master and deal with conflicts.
On 02/08/2018 09:18 AM, Mike Beckerle wrote:
> I believe this:
> Is the last commit using the old file structure, old packages, etc.
> I suspect it would be prudent to make a tag for this. This would be in case
> some developer has lots of outstanding changes based on earlier commits. They
> could first rebase to here, get everything working again, and then do the
> rebase that changes all the names and such.
> Naming convention? I suspect a somewhat verbose tag name would be better than
> just a numbering convention, as the key concept here is that this is still
> edu.illinois.ncsa daffodil packages. So something with the words "final" and
> "edu.illinois.ncsa" as well as capturing that it is pre-2.1.0 release.