[DISCUSS][MSC] Automation of the technical part of the release process

Hi all, as already mentioned, I will create a mail thread for each epic that we defined for the “Support & Care for Apache Maven” initiative (https://open-elements.com/support-care-maven/). All information about this specific epic can be found at https://github.com/OpenElements/maven-support-c

Re: [DISCUSS] Speed up release process?

ancel > it) > > > > > > > - release vote MUST reach PMC quorum > > > > > > > > > > > > > > Hence, in my reading, the above set of constraints does not > > conflicts > > > > > > with > > &g

Re: [DISCUSS] Speed up release process?

t; > > > > above. As I see, none of the responses I got tackled my original > > > > > deduction > > > > > > (simplified above) :) > > > > > > > > > > > > === > > > > > > > > > > > >

Re: [DISCUSS] Speed up release process?

> inform teammates about it on ML or Slack), person KNOWS he needs to > > > > commit > > > > > for upcoming 72+ hours, so he usually tries to "choose wisely" (with > > > all > > > > > the negative effects) -- what can be a good a r

Re: [DISCUSS] Speed up release process?

n, release early", as the > developer > > > will > > > > "choose wisely" WHEN he can commit his 72+ hours, hence the outcome > is > > > what > > > > we have today: slow pace. > > > > > > > > Because there are so ma

Re: [DISCUSS] Speed up release process?

> > what > > > we have today: slow pace. > > > > > > Because there are so many things so few people checking can miss. > > Release, > > > and in a day 5k people may try it and find critical issues and within a > > > couple days you may fix a ha

Re: [DISCUSS] Speed up release process?

Hi I'm not a member of the developer community here, just a watcher offering a comment from the peanut gallery. On 2022-11-18, Tamás Cservenák wrote: > * vote cannot be vetoed by definition (only release mgr can cancel it). while this is true there also is a rule that says "and more positive bi

Re: [DISCUSS] Speed up release process?

use there are so many things so few people checking can miss. > Release, > > and in a day 5k people may try it and find critical issues and within a > > couple days you may fix a handful of serious issues because you can get > so > > much more feedback. > > > > &

Re: [DISCUSS] Speed up release process?

s is a digression. > > On Sat, Nov 19, 2022 at 1:08 AM Guillaume Nodet wrote: > > > I also fail to see how the 72 hours period is the root cause of any issue > > you have. > > > > Here are a few possible changes that could improve the release process: > > * Rele

Re: [DISCUSS] Speed up release process?

is a digression. On Sat, Nov 19, 2022 at 1:08 AM Guillaume Nodet wrote: > I also fail to see how the 72 hours period is the root cause of any issue > you have. > > Here are a few possible changes that could improve the release process: > * Releases can be done in paral

Re: [DISCUSS] Speed up release process?

Sorry for top posting. At least 72 hours is needed because we are all volunteers and it takes time to validate a release. Also I see that in a few projects (maybe not Maven) the VOTE starts during the weekend and this is a problem because sometimes in the weekend you are not at the keyboard and we

Re: [DISCUSS] Speed up release process?

Le ven. 18 nov. 2022 à 21:40, Tamás Cservenák a écrit : > So Maven cares for us, hence the 72h? I don't get how one is deduced from > another. > > And as they are (and usually are) dependent on each other from perspective > of single release mgr local repo we could release all 150+, at the cost o

Re: [DISCUSS] Speed up release process?

I also fail to see how the 72 hours period is the root cause of any issue you have. Here are a few possible changes that could improve the release process: * Releases can be done in parallel or in batches. * If the fact that master branches are broken while releasing, we could certainly create

Re: [DISCUSS] Speed up release process?

Evidently you know something I don’t, and I hope you’ll explain it to me. For the 3rd time, > Which developers have to pause what activities? — Right now there are usually release votes in parallel. As I pointed out, all 308 could be in parallel. What relevance does your calculation have

Re: [DISCUSS] Speed up release process?

damn me 16848 hours = 702 days = almost TWO YEARS of Maven releases just to build Maven itself. But, if you consider all apache artifacts (almost all, unsure is there other in different groupId) [cstamas@blondie local (master %)]$ find * -type f -name "*.jar" | grep "commons-" | wc -l 45 [cstamas

Re: [DISCUSS] Speed up release process?

as well. Manfred On 2022-11-18 9:55 a.m., Tamás Cservenák wrote: Howdy, My pet peeve these days is our release process. IMHO, we should be able to release ("move") much faster than today. My proposal would be: * vote is "done done" the moment quorum is reached * change the

Re: [DISCUSS] Speed up release process?

David, I agree, and understand. But let me step back a bit: ASF (as it all started around httpd) as a foundation hosts MANY projects wildly different projects, and those projects usually have a handful (few, when compared to Maven) of "deliverables" or "artifacts" being released. Or in other word

Re: [DISCUSS] Speed up release process?

If all 153 projects released at once with 72 hour windows, that would be 72 hours. That’s just as plausible as sequential releases. David Jencks > On Nov 18, 2022, at 11:54 AM, Tamás Cservenák wrote: > > As I wrote, we did have examples of changes + cascading, it is okay. > > But I don't agre

Re: [DISCUSS] Speed up release process?

You are free to do your own research. I’ve seen plenty of “but we want the convenience of <72hr releases” discussions over the years, and the feedback I’ve seen is consistently that the reason for the “should” rather than “must” is to account for emergency security patches etc, not normal relea

Re: [DISCUSS] Speed up release process?

Lets try one question/issue per email… Which developers have to pause what activities. David Jencks > On Nov 18, 2022, at 11:54 AM, Tamás Cservenák wrote: > > As I wrote, we did have examples of changes + cascading, it is okay. > > But I don't agree with your statement about the board, as the

Re: [DISCUSS] Speed up release process?

So Maven cares for us, hence the 72h? I don't get how one is deduced from another. And as they are (and usually are) dependent on each other from perspective of single release mgr local repo we could release all 150+, at the cost of breaking all the 150+ CI jobs and all source builds in the wild f

Re: [DISCUSS] Speed up release process?

Side note: asf is about people not code so maven must care about people and this is why 72h came from. For me dependencies is not a reason to make release < 72h since you can release 10 projects in a single staging - anyone failling rolls back them all but that is the intent anyway right? It means

Re: [DISCUSS] Speed up release process?

As I wrote, we did have examples of changes + cascading, it is okay. But I don't agree with your statement about the board, as they themselves state "should" not "must" for 72h. If it does not cut with them, they should modify the refd page(s). And it's not "we're impatient" either, part of the r

Re: [DISCUSS] Speed up release process?

Which developers have to pause what activities? From previous discussions elsewhere, I’m strongly of the opinion that < 72 hr release votes are intended only for emergency security fixes and similar events, and that “we’re impatient” isn’t going to cut it with the board. It certainly wouldn’t

Re: [DISCUSS] Speed up release process?

David, I just meant that there is a "forced pause" of 72h. T On Fri, Nov 18, 2022 at 7:50 PM David Jencks wrote: > +1 from the sidelines. > > I don’t understand > >>>* current process causes (forced) context switching, and can likely > lead to > human mistakes: when the release vote is announc

Re: [DISCUSS] Speed up release process?

th, hangover after a too successful party, or whatever). And again, unsure what 3 days matter. Release process is already HOURS (just sync is 2+), so let's make it AT LEAST 72h? It should be a push of a button. But I think I described where 72h does matter, in my 1st mail. The answer to "it i

Re: [DISCUSS] Speed up release process?

| Github <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. 18 nov. 2022 à 18:55, Tamás Cservenák a > écrit : > >> Howdy, &g

Re: [DISCUSS] Speed up release process?

va-ee-8-high-performance> Le ven. 18 nov. 2022 à 18:55, Tamás Cservenák a écrit : > Howdy, > > My pet peeve these days is our release process. IMHO, we should be able to > release ("move") much faster than today. > > My proposal would be: > * vote is "done

[DISCUSS] Speed up release process?

Howdy, My pet peeve these days is our release process. IMHO, we should be able to release ("move") much faster than today. My proposal would be: * vote is "done done" the moment quorum is reached * change the wording in the vote email from "Vote open for at least 72 ho

Maven dependency plugin development/release process

Hi A while back I created a PR with a fix for a bug in the maven dependency plugin: https://github.com/apache/maven-dependency-plugin/pull/133 It seems no one has looked at it yet. What is the process to get PRs reviewed, merged and released? Regards, Jonas van Vliet

[GitHub] [maven-site] mthmulders merged pull request #197: Add 'Customise the Maven Release process' blog

mthmulders merged pull request #197: URL: https://github.com/apache/maven-site/pull/197 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

[GitHub] [maven-site] mthmulders opened a new pull request #197: Add 'Customise the Maven Release process' blog

mthmulders opened a new pull request #197: URL: https://github.com/apache/maven-site/pull/197 Add a reference to my own blog post 'Customise the Maven Release process'. The reason I'm creating a merge request is two-fold: 1. I'm not sure if this place on the sit

Re: Questions regarding improving the Apache Commons release process.

Tompkins a écrit : >>>> Stephen, >>>> >>>> I can’t thank you enough for your reply. I’ll take your suggestions and >>>> continue to sandbox around using the maven-release-plugin as a guideline. >>>> >>>> All the best and happy holi

Re: Questions regarding improving the Apache Commons release process.

Stephen Connolly wrote:> On Tue 26 Dec 2017 at 03:10, Rob Tompkins <mailto:chtom...@apache.org>> wrote: Hello all, Pardon, maybe this should have gone to your @user list, but why not ping the dev crew. I’ve been playing around the ideas surrounding our fairly manual release proce

Re: Questions regarding improving the Apache Commons release process.

deline. >>> >>> All the best and happy holidays, >>> -Rob >>> >>>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly >>>> wrote:> >>>> On Tue 26 Dec 2017 at 03:10, Rob Tompkins > <mailto:chtom...@apache.org>> w

Re: Questions regarding improving the Apache Commons release process.

gt;> All the best and happy holidays, >> -Rob >> >>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly >>> wrote:> >>> On Tue 26 Dec 2017 at 03:10, Rob Tompkins <mailto:chtom...@apache.org>> wrote: >>>> Hello all, >>>>

Re: Questions regarding improving the Apache Commons release process.

d have gone to your @user list, but why not ping > >> the dev crew. I’ve been playing around the ideas surrounding our fairly > >> manual release process for the components in Commons, and I was hoping > >> for > >> some insights. > >> > >

Re: Questions regarding improving the Apache Commons release process.

t 03:10, Rob Tompkins <mailto:chtom...@apache.org>> wrote: > >> Hello all, >> >> Pardon, maybe this should have gone to your @user list, but why not ping >> the dev crew. I’ve been playing around the ideas surrounding our fairly >> manual release process for t

Re: Questions regarding improving the Apache Commons release process.

On Tue 26 Dec 2017 at 03:10, Rob Tompkins wrote: > Hello all, > > Pardon, maybe this should have gone to your @user list, but why not ping > the dev crew. I’ve been playing around the ideas surrounding our fairly > manual release process for the components in Commons, and I was ho

Questions regarding improving the Apache Commons release process.

Hello all, Pardon, maybe this should have gone to your @user list, but why not ping the dev crew. I’ve been playing around the ideas surrounding our fairly manual release process for the components in Commons, and I was hoping for some insights. Scripting the version changes isn’t really

Re: I am current working through the core release process

On Sat 25 Mar 2017 at 12:11, Hervé BOUTEMY wrote: > Le samedi 25 mars 2017, 11:56:50 CET Stephen Connolly a écrit : > > On 25 March 2017 at 11:56, Stephen Connolly < > stephen.alan.conno...@gmail.com > > > wrote: > > > > > > Ok I believe I have done everything... > > > > In other words, reply her

Re: I am current working through the core release process

Le samedi 25 mars 2017, 11:56:50 CET Stephen Connolly a écrit : > On 25 March 2017 at 11:56, Stephen Connolly > wrote: > > > > Ok I believe I have done everything... > > In other words, reply here if I have missed doing anything... I still want > to do anything I missed, but just let me know if

Re: I am current working through the core release process

On 25 March 2017 at 11:56, Stephen Connolly wrote: > Ok I believe I have done everything... > > In other words, reply here if I have missed doing anything... I still want to do anything I missed, but just let me know if I missed anything! > Ugh this is a mess for the core release procedure. I

Re: I am current working through the core release process

Ok I believe I have done everything... Ugh this is a mess for the core release procedure. I think it will take another release for me to write it all down and then maybe propose updates to the process for 3.5.1 On 25 March 2017 at 10:38, Hervé BOUTEMY wrote: > Le samedi 25 mars 2017, 09:57:31 C

Re: I am current working through the core release process

Le samedi 25 mars 2017, 09:57:31 CET Stephen Connolly a écrit : > Please do *not* help. yes, useful to ask explicitely for that: not usual :))) > I need to check that I have the full process and some > people "helped" for alpha-1. > > The current process as written needs improvements but I need t

I am current working through the core release process

Please do *not* help. I need to check that I have the full process and some people "helped" for alpha-1. The current process as written needs improvements but I need to do the whole thing to be sure on the changes I'd like to propose -Stephen -- Sent from my phone

Starting release process asf pom version 16, maven-parent version 26 and maven-plugins version 27...

Hi, I would like to start with releasing the asf pom version 16, maven-parent version 26 and maven-plugins version 27... So i would go with first asf, second maven-parent and third maven-plugins ? Any objections or issues which should go into ? If no objections i would go to start with it to

Re: [Discussion] Simplifying the release process and the maven-release-plugin/maven-site-plugin

ns >> done during release seem to work poorly or requiring much repetitive >> configuration for DVCSs. All - not most - devs I have spoken to prefer >> using the native VCS client for their daily work over Maven's VCS >> integration, implying that we might define the scope of the M

Re: [Discussion] Simplifying the release process and the maven-release-plugin/maven-site-plugin

gration into Maven (which is not used other than in the release cases anyways?). Could we simplify the release process and the configuration for Maven-Release-Plugin and Maven-Site-Plugin by making and reacting to a few assumptions? Here goes: 1. The vast majority of Devs/CIs use Maven/SCM

[Discussion] Simplifying the release process and the maven-release-plugin/maven-site-plugin

eneric VCS integration into Maven (which is not used other than in the release cases anyways?). Could we simplify the release process and the configuration for Maven-Release-Plugin and Maven-Site-Plugin by making and reacting to a few assumptions? Here goes: 1. The vast majority of Devs/CIs use

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

?) that will compare the content of an > > archive with an scm tag checkout > > > > Arnaud > > > > > > On Sun, Jul 7, 2013 at 9:31 PM, sebb > > > wrote: > > > > > On 7 July 2013 13:45, Chris Graham > > > wrote: > > > >

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

y the case of derived files. The issue is that the release process is clearly not infallible. > > There is nothing wrong with the process. One of the core tennants of SCM is reproducability. If you were to check the tag out and rebuild it, you should achieve the same result. If you do not,

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

9:31 PM, sebb wrote: > >> On 7 July 2013 13:45, Chris Graham wrote: > >> > In this instance, these files are derived files, so does it matter? > >> > >> I already said that this particular file is probably not an issue. > >> > >> The issue

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

This sort of takes us back to where we started, which is that people believed that the process was infallible. It's basically impossible to prove that the release process is correct. All you can do is try and design it so that it works as well as it can, and fix it when it breaks. > The

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

bb wrote: > >> On 7 July 2013 13:45, Chris Graham wrote: >> > In this instance, these files are derived files, so does it matter? >> >> I already said that this particular file is probably not an issue. >> >> The issue is that the release process is clearly not

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

> > > > I already said that this particular file is probably not an issue. > > > > The issue is that the release process is clearly not infallible. > > > > The assembly plugin does not identify every file it needs to include, > > so spurious files can be pick

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

e: > On 7 July 2013 13:45, Chris Graham wrote: > > In this instance, these files are derived files, so does it matter? > > I already said that this particular file is probably not an issue. > > The issue is that the release process is clearly not infallible. > > The assembl

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

On 7 July 2013 13:45, Chris Graham wrote: > In this instance, these files are derived files, so does it matter? I already said that this particular file is probably not an issue. The issue is that the release process is clearly not infallible. The assembly plugin does not identify every f

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

rce release has the same issue with a file > called javadoc-options-javadoc-resources.xml which must not be in > here. > > >> >>> In any case, I can see why the source-release assembly did the wrong thing >>> here; it's not in target, so not really expect

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

e; it's not in target, so not really expected to be a generated file. > > Yes, that is basically the point I made early on else-thread. > I said that the release process did not guarantee that the source > archive would contain exactly the correct files - no more, no less. > &

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

a generated file. Yes, that is basically the point I made early on else-thread. I said that the release process did not guarantee that the source archive would contain exactly the correct files - no more, no less. The issue here is not that this particular file found its way into the source archive.

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

hiver/pom.properties The file is not in SVN or the source jar As far as I can tell it does not belong in the source zip. The file is unlikely to do any harm, however the fact that it somehow has crept into the source archive points to a problem with the release process. The file is present in all th

Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

do any harm, however the fact that it somehow has crept into the source archive points to a problem with the release process. The file is present in all the WAR source zips back to 2.1 (previously there were no source archives) AFAICT these WAR source archives were built by several different

Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?

that it somehow has crept into the source archive points to a problem with the release process. The file is present in all the WAR source zips back to 2.1 (previously there were no source archives) AFAICT these WAR source archives were built by several different people. It does not seem to be present

Re: Release process updates (try 2)

On Monday, 1 July 2013, Baptiste MATHUS wrote: > Guys, even if not convinced this is really useful, > I suppose voting template could just be adjusted so that the sha1 > or svn revision be added in the VOTE thread, and then get back to code as > usual? +1 > > As it is just a 5 seconds additional

Re: Release process updates (try 2)

Guys, even if not convinced this is really useful, I suppose voting template could just be adjusted so that the sha1 or svn revision be added in the VOTE thread, and then get back to code as usual? As it is just a 5 seconds additional operation to be done by the RM, I think this is acceptable if t

Re: Release process updates (try 2)

Deleting and recreating a Git tag once published is an *extremely* stupid thing to do, at least an order of magnitude more so than the same action in SVN. I sincerely hope that developers in this community would not engage in such activities. Nevertheless, this thread isn't about that, it's about

Re: Release process updates (try 2)

+1 - I agree with Chris. Besides, if something DOES change in the svn/git tag, we get an email notification so we can immediately figure out what's going on. In addition, if you compare what you are voting on to whatever is the latest version of the the tag, if there is any difference

Re: Release process updates (try 2)

> > > > So, if everyone here likes this idea, by all means let's do that. On the > > other hand, if there is no consensus here, I wish that the Foundation > had a > > clearer venue for discussing global policies like this. > > I hope I don't have to argue that it is ASF policy to only release > sou

Re: Release process updates (try 2)

On Mon, Jul 1, 2013 at 7:14 PM, sebb wrote: > On 1 July 2013 07:18, Chris Graham wrote: > > On Mon, Jul 1, 2013 at 4:20 AM, sebb wrote: > > > >> Reminder: all this thread is just about is adding the following lines > >> to vote e-mails: > >> > >> SVN Tag: > >> > >> > https://svn.apache.org/repo

Re: Release process updates (try 2)

On 30 June 2013 23:33, sebb wrote: > On 30 June 2013 19:20, sebb wrote: >> Reminder: all this thread is just about is adding the following lines >> to vote e-mails: >> >> SVN Tag: >> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/ >> (r1496317) > > An alternativ

Re: Release process updates (try 2)

On 1 July 2013 07:18, Chris Graham wrote: > On Mon, Jul 1, 2013 at 4:20 AM, sebb wrote: > >> Reminder: all this thread is just about is adding the following lines >> to vote e-mails: >> >> SVN Tag: >> >> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/ >> (r1496317<

Re: Release process updates (try 2)

On 1 July 2013 07:18, Chris Graham wrote: > On Mon, Jul 1, 2013 at 4:20 AM, sebb wrote: > >> Reminder: all this thread is just about is adding the following lines >> to vote e-mails: >> >> SVN Tag: >> >> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/ >> (r1496317<

Re: Release process updates

On 1 July 2013 08:17, Andreas Gudian wrote: >> 2013/6/26 sebb >: >> > The mission of the ASF is to release software as source, and to ensure >> > that the released source is available under the Apache Licence. >> >> Excuse me but I have always understand the ASF mission as building >> communities

Re: Release process updates

> 2013/6/26 sebb >: > > The mission of the ASF is to release software as source, and to ensure > > that the released source is available under the Apache Licence. > > Excuse me but I have always understand the ASF mission as building > communities around softwares. > Community over Code and not Pro

Re: Release process updates (try 2)

On Mon, Jul 1, 2013 at 4:20 AM, sebb wrote: > Reminder: all this thread is just about is adding the following lines > to vote e-mails: > > SVN Tag: > > https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/ > (r1496317

Re: Release process updates

2013/6/26 sebb : > The mission of the ASF is to release software as source, and to ensure > that the released source is available under the Apache Licence. Excuse me but I have always understand the ASF mission as building communities around softwares. Community over Code and not Process over Code

Re: Release process updates (try 2)

ing a second repo for *any* other piece of software that contains >> the identical hash is pretty low. The chances of finding the same hash in a >> single Git repo is impractically low. I can't see how that is handled, but >> the obvious way would be to just respin the commit so t

Re: Release process updates (try 2)

On 30 June 2013 19:20, sebb wrote: > The mission of the ASF is to release software as source, and to ensure > that the released source is available under the Apache Licence. > > Before a release can be approved it must be voted on by the PMC. > The review process needs to establish that the propos

Re: Release process updates (try 2)

The chances of finding the same hash in a > single Git repo is impractically low. I can't see how that is handled, but > the obvious way would be to just respin the commit so the date meta data > changed and the hash changed. In any case, if that's a flaw, it's a flaw of

Re: Unique Git coordinates (was: Release process updates (try 2))

On 30 June 2013 23:28, Stephen Connolly wrote: > On Sunday, 30 June 2013, sebb wrote: > >> On 30 June 2013 21:56, Fred Cooke > >> wrote: >> >> >> >> OK, so what is the Git command to download a copy of the sources that >> >> >> > are part of the hash? >> >> >> > >> > git checkout >> >> Does not w

Re: Unique Git coordinates (was: Release process updates (try 2))

hash is pretty low. The chances of finding the same hash > in a > > single Git repo is impractically low. I can't see how that is handled, > but > > the obvious way would be to just respin the commit so the date meta data > > changed and the hash changed. In any case

Unique Git coordinates (was: Release process updates (try 2))

t's a flaw of > Git, and can't be avoided. In practice, it's not a flaw at all. > >> It's just sloppy not to do this; if a quality release process is required, >> > so is the SVN rev number. If "good enough" is OK, then it can be omitted >> > b

Re: Release process updates (try 2)

hash changed. In any case, if that's a flaw, it's a flaw of Git, and can't be avoided. In practice, it's not a flaw at all. > It's just sloppy not to do this; if a quality release process is required, > > so is the SVN rev number. If "good enough" is OK,

Re: Release process updates (try 2)

ources that are part of the hash? Don't I need to know something about the Git repo it comes from? Or are Git hashes guaranteed to be universally unique? > It's just sloppy not to do this; if a quality release process is required, > so is the SVN rev number. If "good enough"

Re: Release process updates (try 2)

Fine with me. Thanks for the explanation sebb. Gary On Jun 30, 2013, at 14:20, sebb wrote: > The mission of the ASF is to release software as source, and to ensure > that the released source is available under the Apache Licence. > > Before a release can be approved it must be voted on by the P

Re: Release process updates (try 2)

For Git the only thing that is needed is the unique 40 character hash such as this: FreeAir:youtube-dl fred$ git rev-parse HEAD 48bfb5f2387ab47e1973d9db0782a9af66ffc4e6 It's just sloppy not to do this; if a quality release process is required, so is the SVN rev number. If "good eno

Release process updates (try 2)

The mission of the ASF is to release software as source, and to ensure that the released source is available under the Apache Licence. Before a release can be approved it must be voted on by the PMC. The review process needs to establish that the proposed source release meets those aims. It's all

Re: Release process updates

Hello, I think svn/git are most interesting, as AFAIK all core-plugins reside in these SCMs :-).[1] Being able to easily review the code diff between several takes or releases has a value of it's own IMO. With websvn, gitweb or github e.g., it is quite trivial to create a link which shows the com

Re: Release process updates

Moreover, the discussion is very SVN/GIT centric. The release plugin and continuum (as far as I know) are the primary users of the SCM api. The entire scm api is an abstraction layer that is very cvs/svn centric (for historical reasons) but an abstraction layer all the same, and abstraction layers

Re: Release process updates

rnal project process (dealing with tags, votes and failed internal release attempts) with the final produced artifact. So IMO the project could decide to *stage* and publish foobar-1.0-rc1 (which it actually promotes to maven central), but might in the release process very well make three private att

Re: Release process updates

Revisions are not important for the pom.xml and should not be registered there. It is only important within the artifact to trace back its origins. One location would be the Manifest file[1] by the buildnumber-maven-plugin And you might want to patch the pom.xml which is bundled with the artifac

Re: Release process updates

ith the final produced artifact. So >> IMO the project could decide to *stage* and publish foobar-1.0-rc1 >> (which it actually promotes to maven central), >> but might in the release process very well make three private attempts >> before even rc1 is promoted. >> >

Re: Release process updates

) with the final produced artifact. So IMO the project could decide to *stage* and publish foobar-1.0-rc1 (which it actually promotes to maven central), but might in the release process very well make three private attempts before even rc1 is promoted. That'd make it foobar-1.0-rc§1, foobar-1.0-r

Re: Release process updates

ually promotes to maven central), but might in the release process very well make three private attempts before even rc1 is promoted. That'd make it foobar-1.0-rc§1, foobar-1.0-rc§2 and foobar-1.0-rc§3. The tags go in the poms and we just keep the final tag as a permanent reference. I

Re: Release process updates

Kristian, # could lead to a lot of problems when used with dereferencing http-proxies, because it separates the http-url fragment[1]. AFAIK Debian packages use ~ (tilde) as separator for beta packages which has no special semantics AFAIK in URLs. [1] http://en.wikipedia.org/wiki/Fragment_identifi

Re: Release process updates

2013/6/28 Fred Cooke > Someone else already covered that. The tag can live forever as it always > was in the POM. In the SVN version you can either lie before or after, in > the Git version you can use final or RC and they'll end up pointing at the > same commit. Having said that, I never underst

Re: Release process updates

Someone else already covered that. The tag can live forever as it always was in the POM. In the SVN version you can either lie before or after, in the Git version you can use final or RC and they'll end up pointing at the same commit. Having said that, I never understood why that was done anyway. M

Re: Release process updates

On Friday, 28 June 2013, Fred Cooke wrote: > For git the unique hash is sufficient, you don't really need the tag at > all, they simply point to the unique hash (or another tag, in a chain). If > Git was the SCM of choice, I'd use RCX tags, and then not retag for final, > but rather point the fina

Re: Release process updates

@ Chris Graham email 1 If you had, you'd have seen that the release plugin > uses a svn copy to create the tag. A tag, in this instance is a lebel, or > sym link for a revision. > These two sentences together are pure comedy gold. The second one is purely false. A tag in SVN is nothing more than

  1   2   3   >