> On Jan 22, 2018, at 4:02 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Mon, Jan 22, 2018 at 3:54 PM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> >> >>> On Jan 22, 2018, at 3:44 PM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >>> >>> On Mon, Jan 22, 2018 at 3:25 PM, Matt Sicker <boa...@gmail.com> wrote: >>> >>>> The profiles idea would help a lot for local development and making it >>>> easier to run the relevant unit tests when modifying code. This wouldn't >>>> really help the release process, though, as we'd either need to release >>>> everything in the repo at once, or we'd end up with unreleased modules >>>> being tagged on release of anything else in the same repo. >>>> >>> >>> Ah... but you COULD make it help in the release just as well but putting >>> what you are releasing into the main profile! That's the beauty of it. >>> Sure, you'd tag the whole thing as one. Presumably, you'd think the RM >>> would make sure at least everything compiles ;-) >> >> I don’t understand. If I perform a release for 2.11.0 and skip certain >> modules they are not going to have their versions updated. They will be >> pointing at 2.11.0-SNAPSHOT as a parent even though the parent has been >> changed to 2.11.1-SNAPSHOT. >> > > The way I see it is that you'd update the POM versions _as if_ you were to > release and had released the modules that in fact are skipped. For example, > if log4j-foo is not in the main-modules profile, it's versions would go > from 2.11.0-SNAPSHOT to 2.11.1-SNAPSHOT. I suppose that might means an > adjustment to a current step or an extra step.
That process would be guaranteed to have things messed up and would make users wonder why versions of jars were skipped. Ralph
