0.0-beta-2 < 1.0.0-beta-10 and 1.0.0-beta.1 < 1.0.0-beta.10
according to ComparableVersion.
* 1.0.0-beta-2 > 1.0.0-beta-10, but 1.0.0-beta.2 < 1.0.0-beta.10
according to SemVer 2.0.0
Note: this is mostly a curiosity for me. Even if the Version Range
Spec[2] were to define a `semver`
est the usage of pre-release qualifiers of the
form `beta.` (with a dot) instead of `beta-` (with a hyphen)? This
would improve compatibility between Maven ordering and the ordering
specified by the Semantic Versioning specification[1]. Maven doesn't
really care if the separator is a dot, hyphen
stead of `beta-` (with a hyphen)? This
> would improve compatibility between Maven ordering and the ordering
> specified by the Semantic Versioning specification[1]. Maven doesn't
> really care if the separator is a dot, hyphen or is omitted, but semver
> expects numeric iden
the ordering
specified by the Semantic Versioning specification[1]. Maven doesn't
really care if the separator is a dot, hyphen or is omitted, but semver
expects numeric identifiers to be separated with a dot. Otherwise it
sorts lexicographically: `beta-1`, `beta-10`, `beta-2`.
Since I
sonable service to our users community
>
> Regards,
>
> Hervé
>
> On 2024/03/06 13:58:01 Tamás Cservenák wrote:
> > Howdy,
> >
> > We have several topics that need to be discussed.
> >
> > I. Core Plugin Versioning
> >
> > History: When Maven2 w
>
> I. Core Plugin Versioning
>
> History: When Maven2 was born, and started using plugins "as we know them
> today" (Maven 1 was a very different beast), the Core Plugin versions were
> started as 2.0 on purpose. Just check the Maven Central for historic
Gary,
"core plugins" are controlled by us, and they always followed this
"standard" (version major was showing Maven API level).
But true, for EXTERNAL plugins, this will be quite an interesting thing.
They will probably solve the "migrated to Maven 4 API" by major version
bump.
Maven2 was "shor
On Fri, Mar 8, 2024, 2:56 PM Michael Osipov wrote:
> Am 2024-03-08 um 20:51 schrieb Gary Gregory:
> > IMO, the old version + 0.10 is a recipe for confusion and explanations
> for
> > this and that exception.
>
> I totally agree with you, that is a horrible compromise. Do you see a
> better way to
Think site got slowly replaced by other alternatives - even to document
mojos! - so today it is mainly about us and I also dont think limiting
doxia 2 to maven 4 has much issues, there is no real request from outside
for it AFAIK.
>From a versioning standpoint I see really no reason to mak
I plan to publish an announcement *before* I update anything or bump
reporting plugins to the (now) next minor version. People will always
complain -- regardless of what you do -- if they are unhappy.
I don't expect you to waste to time for site, just skip it mentally. I
will take care.
Am 202
Sorry, 1989!
On Fri, Mar 8, 2024 at 9:10 PM Tamás Cservenák wrote:
> Michael,
>
> I understand, but then all that remains is +10 or +100 in versions,
> trickeries, or whatever...
>
> Be prepared for "this works with that but does not with that other" types
> of JIRA...
> And my guess is that the
Michael,
I understand, but then all that remains is +10 or +100 in versions,
trickeries, or whatever...
Be prepared for "this works with that but does not with that other" types
of JIRA...
And my guess is that the few who still use the site function of Maven will
simply drop it.
A big confusion i
Am 2024-03-08 um 20:56 schrieb Tamás Cservenák:
I agree with Gary,
really really the simplest would be to NOT use Doxia 2 for Maven 3, as
basically that IS the "plugin breakage" we are soon facing.
This is unacceptable for me because that breaks two years of ongoing
effort. I cannot expect pe
roposed and rejected before, but how about
> > >
> > > 1. maven4-compiler-plugin
> > >
> > > -or-
> > >
> > > 2. maven-compiler-plugin (with maven4/maven5/etc classifier)
> > >
> > > In both scenario's, we could still use sem
Am 2024-03-08 um 20:51 schrieb Gary Gregory:
IMO, the old version + 0.10 is a recipe for confusion and explanations for
this and that exception.
I totally agree with you, that is a horrible compromise. Do you see a
better way to reconcile both issues? I don't see any :-(
---
before, but how about
> >
> > 1. maven4-compiler-plugin
> >
> > -or-
> >
> > 2. maven-compiler-plugin (with maven4/maven5/etc classifier)
> >
> > In both scenario's, we could still use semantic versioning as we do
> > right now, and as Mave
2 PM Maarten Mulders
wrote:
> It might've been proposed and rejected before, but how about
>
> 1. maven4-compiler-plugin
>
> -or-
>
> 2. maven-compiler-plugin (with maven4/maven5/etc classifier)
>
> In both scenario's, we could still use semantic versioning as we
It might've been proposed and rejected before, but how about
1. maven4-compiler-plugin
-or-
2. maven-compiler-plugin (with maven4/maven5/etc classifier)
In both scenario's, we could still use semantic versioning as we do
right now, and as Maven users probably expect us to adhere to
Am 2024-03-08 um 17:20 schrieb Guillaume Nodet:
I'm slightly hesitant about that.
It seems to me plugins have mostly been compatible, so we very rarely
used a major version switch, but we do have plugins in 3.12.1 for
example, which would be translated to 3.0.12.1. Not even sure how the
4th digi
esent a breaking change, so from 3.12.1 to
> 3.23.0
>
> Guillaume
>
> Le ven. 8 mars 2024 à 11:19, Tamás Cservenák a écrit :
> >
> > So, can we agree on following (maybe even vote if needed)?
> >
> > I. Core Plugin Versioning
> > Maven3 plugins carr
ative proposal would be to do a 10 unit big jump
in the minor version to represent a breaking change, so from 3.12.1 to
3.23.0
Guillaume
Le ven. 8 mars 2024 à 11:19, Tamás Cservenák a écrit :
>
> So, can we agree on following (maybe even vote if needed)?
>
> I. Core Plugin Versioning
+1
Am 08.03.2024 um 13:00 schrieb Tamás Cservenák:
So, can we agree on following (maybe even vote if needed)?
I. Core Plugin Versioning
Maven3 plugins carry 3.x as the major version number, and Maven4 plugins
will carry 4.x major versions?
II. Consequence: How to interpret Core plugin
lt;https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le ven. 8 mars 2024 à 13:00, Tamás Cservenák a écrit :
> So, can we agree on following (maybe even vote if
So, can we agree on following (maybe even vote if needed)?
I. Core Plugin Versioning
Maven3 plugins carry 3.x as the major version number, and Maven4 plugins
will carry 4.x major versions?
II. Consequence: How to interpret Core plugin versions
See above. In short: the first element is "mave
ugin that includes report as well, report MUST be
>> split out as the first step.
>>
>> T
>>
>> On Fri, Mar 8, 2024 at 11:29 AM Michael Osipov
>> wrote:
>>
>>> Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
>>> > So, can we agree on followin
1:29 AM Michael Osipov
> wrote:
>
>> Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
>> > So, can we agree on following (maybe even vote if needed)?
>> >
>> > I. Core Plugin Versioning
>> > Maven3 plugins carry 3.x as the major version number, and Maven4 plugi
; Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
> > > So, can we agree on following (maybe even vote if needed)?
> > >
> > > I. Core Plugin Versioning
> > > Maven3 plugins carry 3.x as the major version number, and Maven4
> plugins
> > > will carr
at 11:29 AM Michael Osipov wrote:
> Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
> > So, can we agree on following (maybe even vote if needed)?
> >
> > I. Core Plugin Versioning
> > Maven3 plugins carry 3.x as the major version number, and Maven4 plugins
> > wil
Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
So, can we agree on following (maybe even vote if needed)?
I. Core Plugin Versioning
Maven3 plugins carry 3.x as the major version number, and Maven4 plugins
will carry 4.x major versions?
See Maven Site Plugin 4.0, contains fundemantal changes
Sounds good to me.
/Anders (mobile)
Den fre 8 mars 2024 11:19Tamás Cservenák skrev:
> So, can we agree on following (maybe even vote if needed)?
>
> I. Core Plugin Versioning
> Maven3 plugins carry 3.x as the major version number, and Maven4 plugins
> will carry 4.x major v
So, can we agree on following (maybe even vote if needed)?
I. Core Plugin Versioning
Maven3 plugins carry 3.x as the major version number, and Maven4 plugins
will carry 4.x major versions?
II. Consequence: How to interpret Core plugin versions
See above. In short: the first element is "mave
Michael,
I am unsure why it would not work? As I explained in my initial email,
Maven2 plugins were 2.x, Maven3 plugins were 3.x, so why could not Maven4
be 4.x?
I think that "maven plugin" is quite well defined (is not "just a jar").
While I would expect your "bump the major version" for some lib
This is a general problem and cannot be solved. As soon as you need to
break the plugin compat you need to bump the major version. That
breakage does not need to be related to Maven at all.
Upshot: No matter what you do, you will do it wrong. I would rely on
MPLUGIN foo to manage he compat histo
Hey all,
my thoughts on these questions are quite that we should keep it as simple as it
is:
I see value in keeping the versioning and its semantics with the Maven API at
the first slot. This makes it an easy to see indicator and keeps the experience
/knowledge of long time Maven users. About
w.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 6 mars 2024 à 15:16, Tamás Cservenák a écrit :
> +1 to that definition
>
> On Wed, Mar 6, 2024 at 3:14 PM Konrad Windszus wrote:
>
> > Maven Core plugins are listed in https://maven.apache.org/plugin
;plugin" suffix is needed:
>>
>> maven-clean-plugin -> maven-core-clean or maven4-core-clean
>>
>> My preference is "maven4-core-clean"
>>
>> Gary
>>
>> On Wed, Mar 6, 2024 at 8:59 AM Tamás Cservenák
>> wrote:
>>&g
+1 to that definition
On Wed, Mar 6, 2024 at 3:14 PM Konrad Windszus wrote:
> Maven Core plugins are listed in https://maven.apache.org/plugins/.
> But I would say that this versioning policy applies to all plugins in
> groupId org.apache.maven.plugins…..
>
> Konrad
>
> &g
gin
>
> I'm also not sure the "plugin" suffix is needed:
>
> maven-clean-plugin -> maven-core-clean or maven4-core-clean
>
> My preference is "maven4-core-clean"
>
> Gary
>
> On Wed, Mar 6, 2024 at 8:59 AM Tamás Cservenák
> wrote:
> >
>
Maven Core plugins are listed in https://maven.apache.org/plugins/.
But I would say that this versioning policy applies to all plugins in groupId
org.apache.maven.plugins…..
Konrad
> On 6. Mar 2024, at 15:06, Gary Gregory wrote:
>
> One issue from a non-Maven dev (me) is that I hav
these, we MUST align on these IMHO.
T
On Wed, Mar 6, 2024 at 3:05 PM Romain Manni-Bucau
wrote:
> Hi Tamas,
>
> Not sure I really got the issue, is it to do a breaking change without a
> maven-core bump?
>
> I tend to agree with you, ie the versioning is
> $mavenCoreMajor.$
extraordinary case would
probably justify a change of the artifactId.
Konrad
> On 6. Mar 2024, at 14:58, Tamás Cservenák wrote:
>
> Howdy,
>
> We have several topics that need to be discussed.
>
> I. Core Plugin Versioning
>
> History: When Maven2 was born, and starte
;m also not sure the "plugin" suffix is needed:
maven-clean-plugin -> maven-core-clean or maven4-core-clean
My preference is "maven4-core-clean"
Gary
On Wed, Mar 6, 2024 at 8:59 AM Tamás Cservenák wrote:
>
> Howdy,
>
> We have several topics that need to be discus
Hi Tamas,
Not sure I really got the issue, is it to do a breaking change without a
maven-core bump?
I tend to agree with you, ie the versioning is
$mavenCoreMajor.$pluginMajor.$pluginMinor and no patch digit and guess it
works good enough even for users, no?
Best,
Romain Manni-Bucau
Howdy,
We have several topics that need to be discussed.
I. Core Plugin Versioning
History: When Maven2 was born, and started using plugins "as we know them
today" (Maven 1 was a very different beast), the Core Plugin versions were
started as 2.0 on purpose. Just check the Maven C
So you mean maven 5 will need to rename and rerelease all plugins even if
they will be compatible thanks the policy versioning rule + new API?
Npm and webpacks are not great rerefences since they don't aim at being
stable as we intend.
Look at javaee (before the jakarta big bang which broke
The advantage is simple.
With "maven4" in the module name, you don't need a compatibility matrix on
every plugins homepage or readme.
Just look at npm modules and webpack... Tables over tables...
On Sun, 26 Mar 2023, 19:29 Michael Osipov, wrote:
> Am 2023-03-26 um 19:02 schrieb Romain Manni-
Am 2023-03-26 um 19:02 schrieb Romain Manni-Bucau:
@Benjamin what's the addtion of the "4" except looking weird after 1
version since you use semver? It forces 2 changes instead of one without
anything else explicit IMHO.
I fully second that!
--
is for Maven 3.x.
> >
> > We don't have any written documentation about it (or I can't find it), it
> > looks like a traditional agreement.
> >
> > Nowadays Semantic Versioning is very popular and it is understood by
> people
> > and by automatic tools.
; looks like a traditional agreement.
>
> Nowadays Semantic Versioning is very popular and it is understood by people
> and by automatic tools.
> In many cases we use versions which look like Semantic Versioning (x.y.z) -
> but internally we try to classify it in different ways.
>
Am 2023-03-23 um 20:57 schrieb Slawomir Jaranowski:
Hi,
I know that historically plugin versions like 2.x was dedicated to Maven
2.x and versions 3.x is for Maven 3.x.
We don't have any written documentation about it (or I can't find it), it
looks like a traditional agreement.
I wouldn't tie
e 2.x was dedicated to Maven
> 2.x and versions 3.x is for Maven 3.x.
>
> We don't have any written documentation about it (or I can't find it), it
> looks like a traditional agreement.
>
> Nowadays Semantic Versioning is very popular and it is understood by
> people an
i,
>
> I know that historically plugin versions like 2.x was dedicated to Maven
> 2.x and versions 3.x is for Maven 3.x.
>
> We don't have any written documentation about it (or I can't find it), it
> looks like a traditional agreement.
>
> Nowadays Semantic V
Hi,
Think linking maven and maven plugins version does not make sense for most
people since at the end the compat is somehow documented by the
dependencyso using a more common versioning (semver or not) sounds straight
forward.
What would be very bad for me would be a renaming (xxx -> xxx4 for
Hi,
I know that historically plugin versions like 2.x was dedicated to Maven
2.x and versions 3.x is for Maven 3.x.
We don't have any written documentation about it (or I can't find it), it
looks like a traditional agreement.
Nowadays Semantic Versioning is very popular and it is und
slachiewicz closed pull request #37:
URL: https://github.com/apache/maven-site/pull/37
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, ple
slachiewicz closed pull request #37:
URL: https://github.com/apache/maven-site/pull/37
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, ple
>
> > FWIW, I prefer that a project (any project, not just Maven) have a
> > documented versioning policy that says something like “We use Semantic
> > Versioning [1]. We don’t skip version numbers for things someone said a
> > future release might contain. We do have gui
Well said Ralph :-)
Gary
On Wed, Apr 21, 2021, 02:26 Ralph Goers wrote:
> FWIW, I prefer that a project (any project, not just Maven) have a
> documented versioning policy that says something like “We use Semantic
> Versioning [1]. We don’t skip version numbers for things someo
FWIW, I prefer that a project (any project, not just Maven) have a documented
versioning policy that says something like “We use Semantic Versioning [1]. We
don’t skip version numbers for things someone said a future release might
contain. We do have guidance that specifies what is guaranteed
> > > That maven will always fix the latest (stable) version and can
> release
> > > > maintenance branches on demands (lazily)?
> > > >
> > > > Do we write 3.6 and 4 are active and maintained branches currently or
> > do
> > > we
> > &
27;d love we solve that
> > > before next release if possible cause it always create pointless work
> due
> > > to the blurry exchanges on this topic over our website and the net/mail
> > > archives.
> > >
> > >
> > > Le lun. 5 avr. 2021 à 19:51, Romain M
1 à 19:51, Romain Manni-Bucau
> a
> > écrit :
> >
> > >
> > >
> > >
> > > Le lun. 5 avr. 2021 à 17:42, Ralph Goers
> a
> > > écrit :
> > >
> > >> I don’t understand the point. The very next version of Maven di
mail
> > archives.
> >
> >
> > Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau
> a
> > écrit :
> >
> > >
> > >
> > >
> > > Le lun. 5 avr. 2021 à 17:42, Ralph Goers
> a
> > > écrit :
> > &g
>> security fix. Just because the release manager decided to follow a peculiar
> >> version numbering practice unique to Maven doesn’t mean there is a problem.
> >>
> >
> > This had been an issue only because the versioning policy of maven is
> > undefined
ase manager decided to follow a peculiar
>> version numbering practice unique to Maven doesn’t mean there is a problem.
>>
>
> This had been an issue only because the versioning policy of maven is
> undefined.
> If defined it is perfectly fine for me.
>
>
>&g
t;
This had been an issue only because the versioning policy of maven is
undefined.
If defined it is perfectly fine for me.
>
> I don’t know what you mean by random, nor do I know what you mean by a
> stability statement. AFAIK Maven has been very stable from the 2.x versions
> through t
you
>> can require them from a project which does not offer them by themself).
>>
>>
>> --
>> http://bernd.eckenfels.net
>> ____
>> Von: Ralph Goers
>> Gesendet: Sunday, April 4, 2021 9:55:50 PM
>> An: Maven Deve
ich does not offer them by themself).
>
>
> --
> http://bernd.eckenfels.net
>
> Von: Ralph Goers
> Gesendet: Sunday, April 4, 2021 9:55:50 PM
> An: Maven Developers List
> Betreff: Re: Security/Versioning policy proposal
>
> More than likely
offer them by themself).
--
http://bernd.eckenfels.net
Von: Ralph Goers
Gesendet: Sunday, April 4, 2021 9:55:50 PM
An: Maven Developers List
Betreff: Re: Security/Versioning policy proposal
More than likely you will get whatever the next version number happens to
gt;> as far as I know this defends all Maven releases up until now.
>>>
>>
>> Does not cover the last release - and is actually the issue I'm suffering
>> from right now and why i'd like we cover this case: security fixes. As of
>> today it is a mix be
it is a mix between patch (bugfix) and minor lines AFAIK but I'd like
> we explicit it (even just saying on each line "can include bugfixes").
> Said differently: the reverse approach you mention only cover the feature
> evolution but not the most important for versioning poli
we cover this case: security fixes. As of
today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like
we explicit it (even just saying on each line "can include bugfixes").
Said differently: the reverse approach you mention only cover the feature
evolution but not t
ntly: the reverse approach you mention only cover the feature
evolution but not the most important for versioning policy: the security
policy which is the one which hurt right now.
As an user, I want to be able to anticipate the versions i can need staying
as much as possible on a stable version (origi
one or two more sentences to solve that.
Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a
écrit :
> On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau
> wrote:
> >
> > Hi all,
> >
> > What about starting from something like
> > http://tomee.apache.org/security/secu
gt; http://tomee.apache.org/security/security.html for our versioning
> policy.
> >
> > Goal is really to let user plan their versioning policy and ensure there
> is
> > no big surprises in the needed upgrades to have bugfixes.
> >
>
> TBH I don't think we have en
On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau wrote:
>
> Hi all,
>
> What about starting from something like
> http://tomee.apache.org/security/security.html for our versioning policy.
>
> Goal is really to let user plan their versioning policy and ensure there is
>
Hi all,
What about starting from something like
http://tomee.apache.org/security/security.html for our versioning policy.
Goal is really to let user plan their versioning policy and ensure there is
no big surprises in the needed upgrades to have bugfixes.
The tomee one spiritI aligns on the 3.6
+1
2015-09-30 11:12 GMT+02:00 Karl Heinz Marbaise :
> Hi,
>
> i would like to suggest to upgrade all maven-shared components versions to
> 3.0.0 if they use Maven 3.0 dependencies and use JDK 1.6...
>
> (Honestly i have to admit that i already started with Maven Archiver in that
> way but coming t
Hi,
i would like to suggest to upgrade all maven-shared components versions
to 3.0.0 if they use Maven 3.0 dependencies and use JDK 1.6...
(Honestly i have to admit that i already started with Maven Archiver in
that way but coming to Maven Shared utils which is used by maven
archiver to upgr
://www.99soft.org/
On Wed, Aug 22, 2012 at 1:29 PM, Tony Chemit
wrote:
On Wed, 22 Aug 2012 13:22:56 +0200
Olivier Lamy wrote:
2012/8/22 Simone Tripodi :
> Hi all guys,
>
> time ago Robert and I were discussing about versioning the produced
> minified css/js to avoid browser cache
22 Aug 2012 13:22:56 +0200
> Olivier Lamy wrote:
>
>> 2012/8/22 Simone Tripodi :
>> > Hi all guys,
>> >
>> > time ago Robert and I were discussing about versioning the produced
>> > minified css/js to avoid browser cache conflicts,
On Wed, 22 Aug 2012 13:22:56 +0200
Olivier Lamy wrote:
> 2012/8/22 Simone Tripodi :
> > Hi all guys,
> >
> > time ago Robert and I were discussing about versioning the produced
> > minified css/js to avoid browser cache conflicts, I mean, ATM all
> &
2012/8/22 Simone Tripodi :
> Hi all guys,
>
> time ago Robert and I were discussing about versioning the produced
> minified css/js to avoid browser cache conflicts, I mean, ATM all
> fluido skin versions refer to
>
> $relativePath/js/apache-maven-fluido.min.js
> $rela
Hi all guys,
time ago Robert and I were discussing about versioning the produced
minified css/js to avoid browser cache conflicts, I mean, ATM all
fluido skin versions refer to
$relativePath/js/apache-maven-fluido.min.js
$relativePath/js/apache-maven-fluido.min.cs
that could cheat users when
re. Étant
donné que les email peuvent facilement être sujets à la manipulation, nous ne
pouvons accepter aucune responsabilité pour le contenu fourni.
> From: baris...@w.cn
> To: dev@maven.apache.org
> Subject: About Maven3 M2Eclipse Plug-in Versioning Problem
> Date: Mon, 1
No worries... though I need to call a vote to get a 3.0-beta-1 compatible
version published
2010/5/17 Benjamin Bentmann
> Barışcan Güngör wrote:
>
> [...] we
>>
>> could specify a variable for the application version in the parent pom, so
>> that
>> in the child poms we could able to specify th
Barışcan Güngör wrote:
[...] we
could specify a variable for the application version in the parent pom, so that
in the child poms we could able to specify the version by the same variable.
That helps us saving our time for updating version number in each project
upgrade and for reusability.
Oh
You were relying on a bug.
the following xpath:/project/parent/groupId,
xpath:/project/parent/artifactId, xpath:/project/parent/version,
xpath:/project/groupId, xpath:/project/artifactId, xpath:/project/version
cannot ever reference a property as they are all evaluated before the model
is availabl
Barışcan Güngör wrote:
Now the problem is in maven3 (m2eclipse) it gives a warning
that says “version must be a constant instead of a variable”.
A POM deployed to a repository must be self-contained in the way that
all information required to process it (e.g. calculate the effective
POM) mus
Hi,
At first, thanks for your attention and time to read.
In our enterprise applications we use MyEclipse 8.5 with
M2Eclipse maven3 plug-in support. Before begining to use maven3, with maven2 we
could specify a variable for the application version in the parent pom, so that
in the child
On 13/11/2009, at 1:08 AM, Brian Fox wrote:
> There should be a start and end range for the tests. These new ones
> start in alpha-4-snapshot and end ]
ok, I've fixed these 2 and 4361 based on your other comment (though I haven't
changed the JIRA version of that issue).
I also included all ver
There should be a start and end range for the tests. These new ones
start in alpha-4-snapshot and end ]
On Thu, Nov 12, 2009 at 8:20 AM, Brett Porter wrote:
> Hi,
>
> I ran the ITs against 3.0-alpha-3 and got a number of failures.
>
> Several of those are because they are fixed in 3.0-alpha-4 but
Hi,
I ran the ITs against 3.0-alpha-3 and got a number of failures.
Several of those are because they are fixed in 3.0-alpha-4 but marked to run
for all versions:
- mng4412OfflineModeInPlugin
- mng4433ForceParentSnapshotUpdate
Before correcting anything I would like to check I understand the po
Can you avoid cross posting? I went to reply to this on d...@mojo and
it had the reply-to of this list as gmail merges the messages.
If you aren't getting the answers you're seeking on d...@mojo you can
post here to point people at it, but cross posting in general is kinda
evil :)
Thanks,
OK, here is the problem set:
For animal-sniffer, we need to have signatures of each of the java runtime
libraries (i.e. the animal smells/scents)
That way animal-sniffer can detect whether you are compatible with a
specific java runtime library.
Initially I was going to have these signatures as
he.org/repos/asf/maven/doxia/doxia-sitetools/branc
> > > >>>hes/doxia-sitetools-1.0.x/
> > > >>
> > > >> I didn't remember this branch... Thanks to refresh my memory :)
> > > >>
> > > >> So, I suggest also t
One side remark about the site: for doxia-1.1 (was 1.0-beta-1) we have modified
the apt format with the plan to render obsolete the original apt used in maven
2.0.x. If we are going to support and maintain both doxia-1.0 (was alpha branch)
and doxia-1.1 then we have to keep both formats docum
>>
> >> So, I suggest also to create an external on these branches. I propose:
> >> https://svn.apache.org/repos/asf/maven/doxia/1.0-x with
> >> doxia
> https://svn.apache.org/repos/asf/maven/doxia/doxia/branches/doxia-1.0.x/
> >>
> https://svn.apache.org/repos/asf/maven/doxia/1.0-x with
> doxia
> https://svn.apache.org/repos/asf/maven/doxia/doxia/branches/doxia-1.0.x/
> doxia-sitetools
> https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-1.0.x/
>
> Also, think to u
itetools/branches/doxia-1.0.x/
Also, think to update the scm tag in the poms :)
>> - apply new versioning in pom
>
> Yes, either before the release or during release:prepare, for both the
> branch and trunk.
Before is better IMHO
>> What else?
>
> For the 1.0 release
1 - 100 of 307 matches
Mail list logo
