Re: [All] What's in a "beta" release?
On 30 August 2018 at 15:35, Gary Gregory wrote: > But SNAPSHOT builds _are_ publicly available on repository.apache.org. Sure > they come and go and you cannot rely on their permanence. Just about all our code is available from URLs that don't require logins. However only formal releases should be announced to the general public. Other links should be confined to pages intended for Commons developers > Gary > > On Thu, Aug 30, 2018, 04:50 sebb wrote: > >> SNAPSHOT builds must only be published to Commons developers. >> They cannot be published on public download pages. >> >> Also they may disappear or be replaced at any time. >> >> Beta builds are subject to a release VOTE, and so can be published in >> the usual way. >> Once published, they are permanently available. >> >> On 30 August 2018 at 09:38, Benedikt Ritter wrote: >> > What's the difference to a nightly build being published to the Apache >> > Snapshot repo? >> > >> > Benedikt >> > >> > Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory < >> > garydgreg...@gmail.com>: >> > >> >> We do not have hard rules for betas AFAIK. IMO, only a beta can depend >> on >> >> another beta, for example see HttpComponents. We should not release a >> >> non-beta that depends on a beta. I think breaking BC is to be expected >> in >> >> an alpha and less so in a beta. Changing package names and coordinates >> from >> >> one beta to the next seems a bit excessive but I would not object to it. >> >> >> >> Gary >> >> >> >> On Wed, Aug 29, 2018, 10:36 Gilles >> wrote: >> >> >> >> > Hello. >> >> > >> >> > Do you have an idea of what it would take to automate "beta" >> >> > releases? >> >> > By this I mean: take a component (at some state) and create >> >> > a branch (with all the necessary adaptations) to become an >> >> > official release. >> >> > >> >> > Are "beta" releases subject to the same BC requirements as >> >> > "ordinary" ones? Concretely, suppose that several releases >> >> > will be necessary: Do they have to change top-level package >> >> > name? >> >> > >> >> > Can a (non-"beta") release (of some component) depend on a >> >> > "beta" release (of another component)? Or has the former to >> >> > be a "beta" too? >> >> > >> >> > Rationale: I imagine that uploading to "Maven Central" may >> >> > help correcting the misrepresentation of resources available >> >> > from this project. >> >> > >> >> > >> >> > Regards, >> >> > Gilles >> >> > >> >> > >> >> > - >> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> > For additional commands, e-mail: dev-h...@commons.apache.org >> >> > >> >> > >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-weaver] 01/01: Build on Java 10; modification to public API requires major version bump
Java 10 removed, among other things, the activation framework, and it's
easier to dump it than to fool around with the optional dependency, for us
and for users (if there were any). Any objections to my merging this to
master and resuming preparations for, now, a 2.0 release?
Thanks,
Matt
On Thu, Aug 30, 2018, 6:07 PM wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> mbenson pushed a commit to branch java10
> in repository https://gitbox.apache.org/repos/asf/commons-weaver.git
>
> commit 69ef91e50a3fe3b736696c0ddc307e3c5bde0cb3
> Author: Matt Benson
> AuthorDate: Thu Aug 30 18:06:47 2018 -0500
>
> Build on Java 10; modification to public API requires major version
> bump
> ---
> ant/pom.xml| 2 +-
> build-tools/pom.xml| 2 +-
> dist/pom.xml | 2 +-
> maven-plugin/pom.xml | 2 +-
> modules/normalizer/pom.xml | 6 ++--
> .../commons/weaver/normalizer/Normalizer.java | 4 +--
> modules/pom.xml| 2 +-
> modules/privilizer/api/pom.xml | 2 +-
> modules/privilizer/pom.xml | 2 +-
> modules/privilizer/weaver/pom.xml | 2 +-
> .../commons/weaver/privilizer/Privilizer.java | 4 +--
> parent/pom.xml | 2 +-
> pom.xml| 33
> +-
> processor/pom.xml | 2 +-
> .../commons/weaver/model/WeaveEnvironment.java | 15 +-
> 15 files changed, 54 insertions(+), 28 deletions(-)
>
> diff --git a/ant/pom.xml b/ant/pom.xml
> index 247b51f..4407ec4 100644
> --- a/ant/pom.xml
> +++ b/ant/pom.xml
> @@ -22,7 +22,7 @@ under the License.
>
> org.apache.commons
> commons-weaver-parent
> -1.4-SNAPSHOT
> +2.0-SNAPSHOT
> ../parent/pom.xml
>
>
> diff --git a/build-tools/pom.xml b/build-tools/pom.xml
> index f856c89..03ac52f 100644
> --- a/build-tools/pom.xml
> +++ b/build-tools/pom.xml
> @@ -21,7 +21,7 @@ under the License.
>
> org.apache.commons
> commons-weaver-base
> -1.4-SNAPSHOT
> +2.0-SNAPSHOT
>
>4.0.0
>commons-weaver-build-tools
> diff --git a/dist/pom.xml b/dist/pom.xml
> index 32b5cb5..2adc395 100644
> --- a/dist/pom.xml
> +++ b/dist/pom.xml
> @@ -22,7 +22,7 @@ under the License.
>
> org.apache.commons
> commons-weaver-parent
> -1.4-SNAPSHOT
> +2.0-SNAPSHOT
> ../parent/pom.xml
>
>
> diff --git a/maven-plugin/pom.xml b/maven-plugin/pom.xml
> index 2548342..4ddf85d 100644
> --- a/maven-plugin/pom.xml
> +++ b/maven-plugin/pom.xml
> @@ -22,7 +22,7 @@ under the License.
>
> org.apache.commons
> commons-weaver-parent
> -1.4-SNAPSHOT
> +2.0-SNAPSHOT
> ../parent/pom.xml
>
>
> diff --git a/modules/normalizer/pom.xml b/modules/normalizer/pom.xml
> index 9d5378e..fbf6403 100644
> --- a/modules/normalizer/pom.xml
> +++ b/modules/normalizer/pom.xml
> @@ -22,7 +22,7 @@ under the License.
>
> org.apache.commons
> commons-weaver-modules-parent
> -1.4-SNAPSHOT
> +2.0-SNAPSHOT
>
>commons-weaver-normalizer
>Apache Commons Weaver Normalizer
> @@ -206,9 +206,9 @@ under the License.
> ${ant.version}
>
>
> -org.eclipse.jdt.core.compiler
> +org.eclipse.jdt
> ecj
> -4.4.2
> +3.14.0
>
>
>
> diff --git
> a/modules/normalizer/src/main/java/org/apache/commons/weaver/normalizer/Normalizer.java
> b/modules/normalizer/src/main/java/org/apache/commons/weaver/normalizer/Normalizer.java
> index 6d12d42..1bc29fd 100644
> ---
> a/modules/normalizer/src/main/java/org/apache/commons/weaver/normalizer/Normalizer.java
> +++
> b/modules/normalizer/src/main/java/org/apache/commons/weaver/normalizer/Normalizer.java
> @@ -32,8 +32,6 @@ import java.util.Map;
> import java.util.Set;
> import java.util.stream.Stream;
>
> -import javax.activation.DataSource;
> -
> import org.apache.commons.lang3.ArrayUtils;
> import org.apache.commons.lang3.Conversion;
> import org.apache.commons.lang3.Validate;
> @@ -275,7 +273,7 @@ public class Normalizer {
> super.visitEnd();
> final byte[] bytecode = ((ClassWriter) cv).toByteArray();
>
> -final DataSource classfile = env.getClassfile(className);
> +final WeaveEnvironment.Resource classfile =
> env.getClassfile(className);
> env.debug("Writing class %s to %s", className,
> classfile.getName());
> try (OutputStream outputStream = classfile.getOutputStream())
> {
> outputStream.write(bytecode);
> diff --git a/modules/pom.xml b/modules/pom.xml
> index 127682d..ce924dd 100644
> --- a/modules/pom.xml
> +++
Re: [Math] Beta release
Hi. On Thu, 30 Aug 2018 19:28:37 +0100, Stephen Colebourne wrote: What I would love to see it a release of commons-math 3 Is it usual to release an unsupported codebase? If yes, is there someone willing to work on this? with an Automatic-Module-Name for Java 9 modules (potentially the only change). A v3.6.1.1 thus? You could use the release as a way of advertising the progress towards v4. Fine to write a paragraph in the release notes; but I'm not so sure that it would change anything to the current situation. What incentive will people still using v3.6.1 (or lower) have for using v4.0-beta (or contribute to get to v4.0)? Gilles Stephen On Thu, 30 Aug 2018 at 19:16, Gilles wrote: On Thu, 30 Aug 2018 07:35:12 -0700, Gary Gregory wrote: > But SNAPSHOT builds _are_ publicly available on > repository.apache.org. Sure > they come and go and you cannot rely on their permanence. And, perhaps, developers do not check what's available there... Reports keep coming showing that they don't know about the status of "Commons Math". Thus the idea that a beta release might draw to the rejuvenation attempt. A "beta" because it is still a lot of work to fix all the identified issues and we need extra help; a "release" because a lot of work has been done since the last release, providing many bug fixes and other improvements. A release of the development version of CM requires the release of its dependencies: "Commons Numbers" and "Commons Statistics".[1] Both would be "beta" too. Regards, Gilles [1] And also "Commons Geometry" if the code is in a state that's able to replace the "o.a.c.math4.geometry" package. > Gary > > On Thu, Aug 30, 2018, 04:50 sebb wrote: > >> SNAPSHOT builds must only be published to Commons developers. >> They cannot be published on public download pages. >> >> Also they may disappear or be replaced at any time. >> >> Beta builds are subject to a release VOTE, and so can be published >> in >> the usual way. >> Once published, they are permanently available. >> >> On 30 August 2018 at 09:38, Benedikt Ritter >> wrote: >> > What's the difference to a nightly build being published to the >> Apache >> > Snapshot repo? >> > >> > Benedikt >> > >> > Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory < >> > garydgreg...@gmail.com>: >> > >> >> We do not have hard rules for betas AFAIK. IMO, only a beta can >> depend >> on >> >> another beta, for example see HttpComponents. We should not >> release a >> >> non-beta that depends on a beta. I think breaking BC is to be >> expected >> in >> >> an alpha and less so in a beta. Changing package names and >> coordinates >> from >> >> one beta to the next seems a bit excessive but I would not object >> to it. >> >> >> >> Gary >> >> >> >> On Wed, Aug 29, 2018, 10:36 Gilles >> wrote: >> >> >> >> > Hello. >> >> > >> >> > Do you have an idea of what it would take to automate "beta" >> >> > releases? >> >> > By this I mean: take a component (at some state) and create >> >> > a branch (with all the necessary adaptations) to become an >> >> > official release. >> >> > >> >> > Are "beta" releases subject to the same BC requirements as >> >> > "ordinary" ones? Concretely, suppose that several releases >> >> > will be necessary: Do they have to change top-level package >> >> > name? >> >> > >> >> > Can a (non-"beta") release (of some component) depend on a >> >> > "beta" release (of another component)? Or has the former to >> >> > be a "beta" too? >> >> > >> >> > Rationale: I imagine that uploading to "Maven Central" may >> >> > help correcting the misrepresentation of resources available >> >> > from this project. >> >> > >> >> > >> >> > Regards, >> >> > Gilles >> >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [release-plugin] multimodule sites
To answer my own question, we already have JaCoCo reporting configured, so I am going to remove javancss rather than be hobbled in terms of what code we can write. Matt On Thu, Aug 30, 2018, 2:43 PM Matt Benson wrote: > It ended up being quite easy to get the unit test to pass, though the new > functionality is no more tested than was the existing username/password > functionality. > > I do find in attempting to generate the site that, despite the plugin's > having been set to build with Java 8, it seems that the javancss report > that is configured is unable to parse :: syntax and no new release of the > plugin is available. Can we remove or replace this plugin? > > Matt > > On Wed, Aug 29, 2018, 8:48 PM Rob Tompkins wrote: > >> >> >> > On Aug 29, 2018, at 7:16 PM, Matt Benson wrote: >> > >> >> On Wed, Aug 29, 2018, 5:41 PM Rob Tompkins wrote: >> >> >> >> >> >> >> >>> On Aug 29, 2018, at 4:43 PM, Matt Benson wrote: >> >>> >> >>> I have opened and resolved [1]. I classified this as a bug. Should we >> >>> consider a 1.4.1 release or just leave the master version at >> >> 1.5-SNAPSHOT? >> >> >> >> I can do either. Seems like a good move before [parent] v48. Thoughts? >> >> >> > >> > +1. I'm also working on a change to consult a server definition from >> Maven >> > settings, as with the maven-scm-publish plugin. I believe my code is >> > correct; however I am still working on the tests since they now expect >> the >> > settings object to have been injected. >> > >> >> Sweet. >> >> > Matt >> > >> >> >> >> -Rob >> >> >> >>> It appears I can do the weaver release using a locally overridden >> >> snapshot >> >>> build of the plugin, so I don't think I'm blocked (or worse, forced >> to do >> >>> things manually :P). >> >>> >> >>> Matt >> >>> >> >>> [1] https://issues.apache.org/jira/browse/COMMONSSITE-122 >> >> >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >>
Re: [release-plugin] multimodule sites
It ended up being quite easy to get the unit test to pass, though the new functionality is no more tested than was the existing username/password functionality. I do find in attempting to generate the site that, despite the plugin's having been set to build with Java 8, it seems that the javancss report that is configured is unable to parse :: syntax and no new release of the plugin is available. Can we remove or replace this plugin? Matt On Wed, Aug 29, 2018, 8:48 PM Rob Tompkins wrote: > > > > On Aug 29, 2018, at 7:16 PM, Matt Benson wrote: > > > >> On Wed, Aug 29, 2018, 5:41 PM Rob Tompkins wrote: > >> > >> > >> > >>> On Aug 29, 2018, at 4:43 PM, Matt Benson wrote: > >>> > >>> I have opened and resolved [1]. I classified this as a bug. Should we > >>> consider a 1.4.1 release or just leave the master version at > >> 1.5-SNAPSHOT? > >> > >> I can do either. Seems like a good move before [parent] v48. Thoughts? > >> > > > > +1. I'm also working on a change to consult a server definition from > Maven > > settings, as with the maven-scm-publish plugin. I believe my code is > > correct; however I am still working on the tests since they now expect > the > > settings object to have been injected. > > > > Sweet. > > > Matt > > > >> > >> -Rob > >> > >>> It appears I can do the weaver release using a locally overridden > >> snapshot > >>> build of the plugin, so I don't think I'm blocked (or worse, forced to > do > >>> things manually :P). > >>> > >>> Matt > >>> > >>> [1] https://issues.apache.org/jira/browse/COMMONSSITE-122 > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Math] Beta release (Was: [All] What's in a "beta" release?)
What I would love to see it a release of commons-math 3 with an Automatic-Module-Name for Java 9 modules (potentially the only change). You could use the release as a way of advertising the progress towards v4. Stephen On Thu, 30 Aug 2018 at 19:16, Gilles wrote: > > On Thu, 30 Aug 2018 07:35:12 -0700, Gary Gregory wrote: > > But SNAPSHOT builds _are_ publicly available on > > repository.apache.org. Sure > > they come and go and you cannot rely on their permanence. > > And, perhaps, developers do not check what's available there... > Reports keep coming showing that they don't know about the status > of "Commons Math". > > Thus the idea that a beta release might draw to the rejuvenation > attempt. A "beta" because it is still a lot of work to fix all > the identified issues and we need extra help; a "release" because > a lot of work has been done since the last release, providing many > bug fixes and other improvements. > > A release of the development version of CM requires the release > of its dependencies: "Commons Numbers" and "Commons Statistics".[1] > Both would be "beta" too. > > > Regards, > Gilles > > [1] And also "Commons Geometry" if the code is in a state that's > able to replace the "o.a.c.math4.geometry" package. > > > Gary > > > > On Thu, Aug 30, 2018, 04:50 sebb wrote: > > > >> SNAPSHOT builds must only be published to Commons developers. > >> They cannot be published on public download pages. > >> > >> Also they may disappear or be replaced at any time. > >> > >> Beta builds are subject to a release VOTE, and so can be published > >> in > >> the usual way. > >> Once published, they are permanently available. > >> > >> On 30 August 2018 at 09:38, Benedikt Ritter > >> wrote: > >> > What's the difference to a nightly build being published to the > >> Apache > >> > Snapshot repo? > >> > > >> > Benedikt > >> > > >> > Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory < > >> > garydgreg...@gmail.com>: > >> > > >> >> We do not have hard rules for betas AFAIK. IMO, only a beta can > >> depend > >> on > >> >> another beta, for example see HttpComponents. We should not > >> release a > >> >> non-beta that depends on a beta. I think breaking BC is to be > >> expected > >> in > >> >> an alpha and less so in a beta. Changing package names and > >> coordinates > >> from > >> >> one beta to the next seems a bit excessive but I would not object > >> to it. > >> >> > >> >> Gary > >> >> > >> >> On Wed, Aug 29, 2018, 10:36 Gilles > >> wrote: > >> >> > >> >> > Hello. > >> >> > > >> >> > Do you have an idea of what it would take to automate "beta" > >> >> > releases? > >> >> > By this I mean: take a component (at some state) and create > >> >> > a branch (with all the necessary adaptations) to become an > >> >> > official release. > >> >> > > >> >> > Are "beta" releases subject to the same BC requirements as > >> >> > "ordinary" ones? Concretely, suppose that several releases > >> >> > will be necessary: Do they have to change top-level package > >> >> > name? > >> >> > > >> >> > Can a (non-"beta") release (of some component) depend on a > >> >> > "beta" release (of another component)? Or has the former to > >> >> > be a "beta" too? > >> >> > > >> >> > Rationale: I imagine that uploading to "Maven Central" may > >> >> > help correcting the misrepresentation of resources available > >> >> > from this project. > >> >> > > >> >> > > >> >> > Regards, > >> >> > Gilles > >> >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math] Beta release (Was: [All] What's in a "beta" release?)
On Thu, 30 Aug 2018 07:35:12 -0700, Gary Gregory wrote: But SNAPSHOT builds _are_ publicly available on repository.apache.org. Sure they come and go and you cannot rely on their permanence. And, perhaps, developers do not check what's available there... Reports keep coming showing that they don't know about the status of "Commons Math". Thus the idea that a beta release might draw to the rejuvenation attempt. A "beta" because it is still a lot of work to fix all the identified issues and we need extra help; a "release" because a lot of work has been done since the last release, providing many bug fixes and other improvements. A release of the development version of CM requires the release of its dependencies: "Commons Numbers" and "Commons Statistics".[1] Both would be "beta" too. Regards, Gilles [1] And also "Commons Geometry" if the code is in a state that's able to replace the "o.a.c.math4.geometry" package. Gary On Thu, Aug 30, 2018, 04:50 sebb wrote: SNAPSHOT builds must only be published to Commons developers. They cannot be published on public download pages. Also they may disappear or be replaced at any time. Beta builds are subject to a release VOTE, and so can be published in the usual way. Once published, they are permanently available. On 30 August 2018 at 09:38, Benedikt Ritter wrote: > What's the difference to a nightly build being published to the Apache > Snapshot repo? > > Benedikt > > Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory < > garydgreg...@gmail.com>: > >> We do not have hard rules for betas AFAIK. IMO, only a beta can depend on >> another beta, for example see HttpComponents. We should not release a >> non-beta that depends on a beta. I think breaking BC is to be expected in >> an alpha and less so in a beta. Changing package names and coordinates from >> one beta to the next seems a bit excessive but I would not object to it. >> >> Gary >> >> On Wed, Aug 29, 2018, 10:36 Gilles wrote: >> >> > Hello. >> > >> > Do you have an idea of what it would take to automate "beta" >> > releases? >> > By this I mean: take a component (at some state) and create >> > a branch (with all the necessary adaptations) to become an >> > official release. >> > >> > Are "beta" releases subject to the same BC requirements as >> > "ordinary" ones? Concretely, suppose that several releases >> > will be necessary: Do they have to change top-level package >> > name? >> > >> > Can a (non-"beta") release (of some component) depend on a >> > "beta" release (of another component)? Or has the former to >> > be a "beta" too? >> > >> > Rationale: I imagine that uploading to "Maven Central" may >> > help correcting the misrepresentation of resources available >> > from this project. >> > >> > >> > Regards, >> > Gilles >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] What's in a "beta" release?
But SNAPSHOT builds _are_ publicly available on repository.apache.org. Sure they come and go and you cannot rely on their permanence. Gary On Thu, Aug 30, 2018, 04:50 sebb wrote: > SNAPSHOT builds must only be published to Commons developers. > They cannot be published on public download pages. > > Also they may disappear or be replaced at any time. > > Beta builds are subject to a release VOTE, and so can be published in > the usual way. > Once published, they are permanently available. > > On 30 August 2018 at 09:38, Benedikt Ritter wrote: > > What's the difference to a nightly build being published to the Apache > > Snapshot repo? > > > > Benedikt > > > > Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory < > > garydgreg...@gmail.com>: > > > >> We do not have hard rules for betas AFAIK. IMO, only a beta can depend > on > >> another beta, for example see HttpComponents. We should not release a > >> non-beta that depends on a beta. I think breaking BC is to be expected > in > >> an alpha and less so in a beta. Changing package names and coordinates > from > >> one beta to the next seems a bit excessive but I would not object to it. > >> > >> Gary > >> > >> On Wed, Aug 29, 2018, 10:36 Gilles > wrote: > >> > >> > Hello. > >> > > >> > Do you have an idea of what it would take to automate "beta" > >> > releases? > >> > By this I mean: take a component (at some state) and create > >> > a branch (with all the necessary adaptations) to become an > >> > official release. > >> > > >> > Are "beta" releases subject to the same BC requirements as > >> > "ordinary" ones? Concretely, suppose that several releases > >> > will be necessary: Do they have to change top-level package > >> > name? > >> > > >> > Can a (non-"beta") release (of some component) depend on a > >> > "beta" release (of another component)? Or has the former to > >> > be a "beta" too? > >> > > >> > Rationale: I imagine that uploading to "Maven Central" may > >> > help correcting the misrepresentation of resources available > >> > from this project. > >> > > >> > > >> > Regards, > >> > Gilles > >> > > >> > > >> > - > >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> > For additional commands, e-mail: dev-h...@commons.apache.org > >> > > >> > > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [All] What's in a "beta" release?
SNAPSHOT builds must only be published to Commons developers. They cannot be published on public download pages. Also they may disappear or be replaced at any time. Beta builds are subject to a release VOTE, and so can be published in the usual way. Once published, they are permanently available. On 30 August 2018 at 09:38, Benedikt Ritter wrote: > What's the difference to a nightly build being published to the Apache > Snapshot repo? > > Benedikt > > Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory < > garydgreg...@gmail.com>: > >> We do not have hard rules for betas AFAIK. IMO, only a beta can depend on >> another beta, for example see HttpComponents. We should not release a >> non-beta that depends on a beta. I think breaking BC is to be expected in >> an alpha and less so in a beta. Changing package names and coordinates from >> one beta to the next seems a bit excessive but I would not object to it. >> >> Gary >> >> On Wed, Aug 29, 2018, 10:36 Gilles wrote: >> >> > Hello. >> > >> > Do you have an idea of what it would take to automate "beta" >> > releases? >> > By this I mean: take a component (at some state) and create >> > a branch (with all the necessary adaptations) to become an >> > official release. >> > >> > Are "beta" releases subject to the same BC requirements as >> > "ordinary" ones? Concretely, suppose that several releases >> > will be necessary: Do they have to change top-level package >> > name? >> > >> > Can a (non-"beta") release (of some component) depend on a >> > "beta" release (of another component)? Or has the former to >> > be a "beta" too? >> > >> > Rationale: I imagine that uploading to "Maven Central" may >> > help correcting the misrepresentation of resources available >> > from this project. >> > >> > >> > Regards, >> > Gilles >> > >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] SHA256/512 hashes
On 30 August 2018 at 11:19, Thomas Vandahl wrote: > On 28.08.18 12:03, sebb wrote: >> On 28 August 2018 at 09:25, Mark Struberg wrote: This is unlikely to happen as long as it does not cover multi-module builds >>> >>> The maven-release-plugin covers multi-module releases since many years. >>> >>> In the projects I'm working on there is no 'release manager'. >>> _Everybody_ can do releases without having to know anything special. >>> This is where the maven-release-plugin really shines. >>> Just use mvn release:prepare + mvn release:perform and be done. >> >> If it works first time. > > I think the release plugin does quite a good job in resuming broken > build processes, rolling back etc. Only for the RM. Meanwhile, trunk has been changed. >> >> The problem is that the Maven release plugin design assumes that the >> first release attempt will succeed. >> As such, it updates trunk to the new snapshot version. >> (This causes issues with CI builds) > > You are free to choose whatever developmentVersion should be recorded. It should not be necessary to downdate the new version. >> It also assumes that the current workspace does not contain anything >> it should not. > > I actually consider this an advantage. It helps you to avoid > inconsistent source trees. Huh? If a local workspace contains spurious files, by definition it is inconsistent. > If you want to get around this, see > checkModificationExcludeList of the prepare goal. Again, it should be the default to use a clean checkout of the tag for building the binary/source artifacts. > Bye, Thomas > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] SHA256/512 hashes
On 29.08.18 01:18, sebb wrote: >> It doesn't check out the tag into a separate directory to build the release >> artifacts? > > Last time I checked it did not. The release:perform goal does this and always did. See target/checkout. Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] SHA256/512 hashes
On 28.08.18 12:03, sebb wrote: > On 28 August 2018 at 09:25, Mark Struberg wrote: >>> This is unlikely to happen as long as it does not cover multi-module builds >> >> The maven-release-plugin covers multi-module releases since many years. >> >> In the projects I'm working on there is no 'release manager'. >> _Everybody_ can do releases without having to know anything special. >> This is where the maven-release-plugin really shines. >> Just use mvn release:prepare + mvn release:perform and be done. > > If it works first time. I think the release plugin does quite a good job in resuming broken build processes, rolling back etc. > > The problem is that the Maven release plugin design assumes that the > first release attempt will succeed. > As such, it updates trunk to the new snapshot version. > (This causes issues with CI builds) You are free to choose whatever developmentVersion should be recorded. > It also assumes that the current workspace does not contain anything > it should not. I actually consider this an advantage. It helps you to avoid inconsistent source trees. If you want to get around this, see checkModificationExcludeList of the prepare goal. Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] What's in a "beta" release?
What's the difference to a nightly build being published to the Apache Snapshot repo? Benedikt Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory < garydgreg...@gmail.com>: > We do not have hard rules for betas AFAIK. IMO, only a beta can depend on > another beta, for example see HttpComponents. We should not release a > non-beta that depends on a beta. I think breaking BC is to be expected in > an alpha and less so in a beta. Changing package names and coordinates from > one beta to the next seems a bit excessive but I would not object to it. > > Gary > > On Wed, Aug 29, 2018, 10:36 Gilles wrote: > > > Hello. > > > > Do you have an idea of what it would take to automate "beta" > > releases? > > By this I mean: take a component (at some state) and create > > a branch (with all the necessary adaptations) to become an > > official release. > > > > Are "beta" releases subject to the same BC requirements as > > "ordinary" ones? Concretely, suppose that several releases > > will be necessary: Do they have to change top-level package > > name? > > > > Can a (non-"beta") release (of some component) depend on a > > "beta" release (of another component)? Or has the former to > > be a "beta" too? > > > > Rationale: I imagine that uploading to "Maven Central" may > > help correcting the misrepresentation of resources available > > from this project. > > > > > > Regards, > > Gilles > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
