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. Gary > > If I assume all the pom versions are the same at 2.11.0-SNAPSHOT and only > want to release the mongodb plugin it will update the parent pom and > mongodb pom to the next version - let’s say 2.11.1-SNAPSHOT. I now cannot > release log4j as 2.11.0 since the parent pom has already released 2.11.0. > So you are going to have version numbers skipping all around. > > Ralph > > >
