Can't wait to see it integrated, as I will add another PR based on the
previous one to emit a message and deprecate that new method.
Do I need to do something to have the PR merged?
On Sun, 29 Dec 2019, 17:38 Enrico Olivelli, wrote:
> Il dom 29 dic 2019, 16:02 Benjamin Marwell ha
> scritto:
>
> > PR is updated.
> >
> > I found out that they might switch to semantic versioning as soon as they
> > have cleaned the API:
> https://github.com/checkstyle/checkstyle/issues/3709
> >
> > That also means: the faster the current PR is integrated, the better -
> less
> > breaking changes for users.
> >
>
> And we should cut a release of Maven plugin
>
> Enrico
>
> >
> >
> > On Mon, 23 Dec 2019, 18:00 Romain Manni-Bucau,
> > wrote:
> >
> > > Le lun. 23 déc. 2019 à 17:51, Benjamin Marwell a
> > > écrit :
> > >
> > > > Sounds good to me.
> > > >
> > > > A new major is not needed for my PR, but needed for future versions
> of
> > > > checkstyle. Depends on how fast they actually remove that method.
> > > >
> > >
> > > We can also just try catch the missing method, will not break us and
> work
> > > with both version
> > >
> > >
> > > > 3 is implemented via 2.
> > > >
> > >
> > > It is more checkstyle side vs maven side but can be
> > >
> > >
> > >
> > > >
> > > >
> > > > On Mon, 23 Dec 2019, 16:50 Romain Manni-Bucau, <
> rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > What about steps?
> > > > >
> > > > > 1. Ask them to grab the plugin (with our support pby)
> > > > > 2. If 1 fails, semver and we align on that somehow in our
> versioning
> > > > > (likely a new major?)
> > > > > 3. More tolerant fallback respecting user configured version, no
> user
> > > > > breaking/enforced change (it hurts way too much even if nicer for
> us)
> > > > >
> > > > > Wdyt?
> > > > >
> > > > >
> > > > > Le lun. 23 déc. 2019 à 16:44, Benjamin Marwell >
> > a
> > > > > écrit :
> > > > >
> > > > > > Furthermore,
> > > > > >
> > > > > > if we do not drop using that method, maven will throw an
> exception.
> > > > Maven
> > > > > > will, not checkstyle.
> > > > > >
> > > > > > I do not think that should be happening (from a user
> perspective).
> > > > > >
> > > > > > It's an easy fix for maven. As soon as the checkstyle Plugin
> > required
> > > > > > checkstyle 8.24 or higher, it the plugin should go to 4.x (new
> > major
> > > > > > version). Simple as that.
> > > > > >
> > > > > > I am even willing to implement a Checkstyle version check to
> > explain
> > > > the
> > > > > > incompatibilities of checkstyle 8.24 and above. It's not much
> work
> > > and
> > > > > will
> > > > > > be helpful to users. Seeing some error ("TreeeWalker does not
> > allow
> > > > the
> > > > > > subelement LineLength") is not helpful by itself. It's easy to
> > > document
> > > > > and
> > > > > > easy to detect.
> > > > > >
> > > > > > Also, why not ask the checkstyle team to adapt semantic
> versioning?
> > > > > Asking
> > > > > > doesn't cost anything afaik.
> > > > > >
> > > > > >
> > > > > > On Mon, 23 Dec 2019, 15:35 Falko Modler,
> wrote:
> > > > > >
> > > > > > > Hi Mark,
> > > > > > >
> > > > > > > > The maven-checkstyle-plugin is rather pretty much hardcoded
> to
> > a
> > > > > > > specific checkstyle version. While you _could_ technically
> > exchange
> > > > the
> > > > > > > checkstyle dependency it is not really intended.
> > > > > > >
> > > > > > >
> > > > > > > Are you sure it is not really intended? It is actually
> > > _documented_:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html
> > > > > > >
> > > > > > > I've been using it this way for many years and I am sure many
> > other
> > > > > > > users have done the same.
> > > > > > >
> > > > > > > Best regards,
> > > > > > >
> > > > > > > Falko
> > > > > > >
> > > > > > >
> > > > > > > Am 23.12.2019 um 12:57 schrieb Mark Struberg:
> > > > > > > > But the main purpose is not to have multiple frameworks run
> > with
> > > > it.
> > > > > > > That's the main difference to surefire.
> > > > > > > >
> > > > > > > > The maven-checkstyle-plugin is rather pretty much hardcoded
> to
> > a
> > > > > > > specific checkstyle version. While you _could_ technically
> > exchange
> > > > the
> > > > > > > checkstyle dependency it is not really intended.
> > > > > > > >
> > > > > > > > The 'compatibility' layer is rather only important for the
> > > > checkstyle
> > > > > > > configuration. That part should really remain stable. If not,
> we
> > > have
> > > > > to
> > > > > > up
> > > > > > > to major version.
> > > > > > > >
> > > > > > > > LieGrue,
> > > > > > > > strub
> > > > > > > >
> > > > > > > >
> > > > > > > >> Am 23.12.2019 um 12:34 schrieb Romain Manni-Bucau <
> > > > > > > rmannibu...@gmail.com>:
> > > > > > > >>
> > > > > > > >> Point is it is the only way to not break end user since it
> > gives
> > > > us
> > > > > > the
> > > > > > > >> control of which version
