On Mon, Jan 22, 2018 at 4:22 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> > > > 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. > How is that different than having some jars produced out of another repo and not releasing from that repo? Gary > > Ralph > > >
