+1 to Jorg's comments ;) I believe what Jorg says is that process is _manual_: - do something NOW (merge PR, write email for vote, ...) - come back after 3 days (and do something more...) (what if you get a baby in between?)
Ideally, all you'd need is to start a small snowball: merge the PR, and initiate a release (by filling in a form of some app?). Then, the app could spin up a vote, that once votes are there, could respond to ML about vote results, would spin up a release, deploy site, etc.... without any assistance :) And during all that you are blissfully looking at another PR :) Central as collaborative platform... is really great idea, while it is != staging at all. Staging is merely meant as QA, not in sense Jorg explains... Thanks, T On Sun, May 1, 2016 at 11:44 PM Karl Heinz Marbaise <[email protected]> wrote: > Hi Jörg, > On 5/1/16 10:18 PM, Hohwiller, Jörg wrote: > > Hi there, > > > > I wanted to share some thoughs I had recently. Maven introduced a > > revolution to the Java world and made a really big step for dependency > > and build management. Open-Source projects are more productive with > maven. > > However, in the last years DevOps showed up and projects start to > > continuously build releases in some cases with a fully automated build > > pipeline. > > > > When I look at open-source development around I see that we have great > > infrastructure with github and pull-requests, etc. > > Hm..Apache accepts pull request as well as MojoHaus > > > But as a downside I also see slow and over-complex processes to get > > something released (see e.g. > > http://www.mojohaus.org/development/performing-a-release.html - wow that > > is not really lean). > > Sorry to say that, but you haven't had the opportunity to see over > complex processes... > > Simply make a release and open the VOTE for 3 Days (with lazy > census)..what is so complex about that? Yes you need to do some things: > > make a release: > > mvn -B release:prepare release:perform (gpg signing) > > go to target/checkout > > mvn site site:stage scm-publish:publish-scm > > and send an email for VOTE and wait the result and than click on the > release button for publishing the artifacts to Central... > > Hm..? > > > Furthermore if you don't like it than simply start a VOTE to change > that...What exactly is the problem herer? > > I think that those three days are a good trade off between speed and the > options for developers to react cause not all developers are sitting in > front of the keyboards and just waiting someone will start a VOTE (they > are doing other things as well)... > > > > In order not to fingerpoint someone I will pick myself: I got a > > pull-request from someone for servicedocgen-maven-plugin that I maintain > > at mojohaus. I reviewed the PR and merged it. Unfortunately, I was very > > busy then and did not create a release for two month now. It might not > > take that much, but still too much. I want to question why do we need > > all this stuff and the votings, etc. > > Because the community which means the Devs of MojoHaus have decided to > do so...(I'm a member of this as well)... > > BTW: Clearly saying to discuss things here on Apache Maven Dev list > which belong to MojoHaus is not a good idea... > > For apache the situation is a little bit different, cause there are some > other aspects important...(Like legals etc.)...but no one prevents you > from starting a release.... > > > And yes sometimes mojohaus/apache maven devs are busy...so those are > open source projects ? I don't understand the remarks ? > > > > > So assume the following future vision for a maven project: > > > > * When a pull request passed (travis, coveralls, etc.) and gets merged a > > CI system automatically builds a release (no need to get PGP keys per > > developer just one setup once for the project CI). The release simply > > gets a timestamp as version-identifier (yyyyMMdd-hhmmss). > > Using PGP etc. is very important in particular related to discussions > about trust and security...(of course only two aspects of that)... > > You can remember a feew weeks ago as a single NPM developer could remove > artifacts from NPM which broke thousands of builds? This showed me that > the NPM people don't want to learn from the experiences of Maven central > already had.... > > Apart from that this would produces a release per commit which usually > not a good idea...CI/CD is the opportunity to make every state a release > ...So furthermore you can use staging in repository managers like Nexus > to handle such things? > > > > > * Now besides the project being responsible for quality (by having good > > tests and only accepting PRs after reasoable review) the community > > (artifact users) could also help and do additional quality assurance. > > This contradicts to the previous suggestions... > > The thing you mentioned...the community is important and must give > feedback which is not always the case or not in the number we wished it > should be.... > > > > Assume maven-central would become a collaborative platform where the > > users of artifacts could vote and label artifact releases. Add comments, > > link CVE or bug reports, etc. Vote +1/-1 on quality or security... > > This is more or less already done via the staging before going to Maven > Central...this is what the 72 hours VOTE times is for... > > Why should they put that on central...the projects are responsible... > Yes you could imagine this ...but in real life i don't see it...cause > someone needs to maintain the platform Central in this way...who should > do that? > > I have large doubts that a users will vote on Central for a release > ...cause they are blaming things which do not work (see for example > StackOverFlow) but not filling a JIRA or at least mail on the mailing > list etc. > > > > > > * Still the project releasing the artifacts could label releases and > > associate minor/major release numbers to branches. > > Why should we/others associate minor/major release numbers to branches? > Which advantages should that give ? > > SemVer.org shows better ideas from the point of view what the artifacts > are doing for users...... > > > > > > In such case however dependencies would not point to a version like > > (4.2.1.RELEASE) but instead to 20160501-235901. In order to pick the > > right technical version you would lookup the collaborative meta data. > > I do not expect everybody to shout hurray to this rought idea. But I > > would be happy if people can think about it and may combine it with > > other ideas so we get even better in the future some day. > > Why should i use something weird like 20160401-232211/20160401-232212 > instead of 1.0.0/1.0.1 ? Where is the difference ? What does this mean? > > I don't see advantages in comparsion to 1.0.0 / 1.0.1 more the contrary... > > > > > > See also > > https://dzone.com/articles/continuous-releasing-maven > > If we are talking about CI/Cd than using release plugin might not be the > best choice...than using versions-maven-plugin etc. are better > alternatives..Furthermore automatic merging in Jenkins etc. can be done > as well...and creating a release can be done within a pipeline without > any problems... > > > > https://devopsnet.com/2012/02/21/continuous-delivery-using-maven/ > > If you have taken a deeper look during the last months...there are > several activities to make the life cycle more flexible in different > ways...or to be more accurate to make the way open to change things... > > For example: > https://issues.apache.org/jira/browse/MNG-5697 > > > > > > I would love to see that maven better supports flexible handling of the > > version for the development > > view while it could simply stay as it is for > > the consumer view. When I use variables in versions of POMs (and I do > > that in every project today e.g. in combination with > > flatten-maven-plugin) I always get warnings from Maven saying: > > [WARNING] Some problems were encountered while building the effective > > model for ... > > [WARNING] 'version' contains an expression but should be a constant. > > Than you are using a wrong Maven version...starting from Maven 3.2.1 you > can use things like this in your version: > > from the release notes: > http://maven.apache.org/docs/3.2.1/release-notes.html > <quote> > A simple change to prevent Maven from emitting warnings about versions > with property expressions. Allowed property expressions in versions > include ${revision}, ${changelist}, and ${sha1}. These properties can be > set externally, but eventually a mechanism will be created in Maven > where these properties can be injected in a standard way. For example > you may want to glean the current Git revision and inject that value > into ${sha1}. This is by no means a complete solution for continuous > delivery but is a step in the right direction. > </quote> > > So you can simply set the version like: > > <version>${revision}</version> > > and than you do: > > mvn -Drevision=1.0 deploy > > or > > mvn -Drevision=1.0-SNAPSHOT deploy > > So where is the problem here? > > > > > Still I see no clear picture how maven will adress these needs that > > obviously many developer seem to have. > > What needs have many developers..? > > We could start a discussions about that...and see if we get a clear > picture where the journey could go... > > > > Issues like MNG-4161, MNG-624 and others were simply closed and not > > fixed. > > MNG-624 would lead to using a version range like JavaScript (NPM) does > etc. and based on the experience we had on version ranges....Furthermore > in the meantime you could use version ranges in parent with next Maven > Release (3.4.0) see > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0 > > > MNG-4161: This can more or less being solved by using > dependencyManagement in parent of the multi module build...Yes not the > optimal solution...but others would need changing the fundamentals of > Maven...and somethings needed to be changed in the pom modell.. > > Apart from that Benson Margulies has something via Extension: (User > Mailing list): > > https://github.com/basis-technology-corp/auto-version-maven-extension > > > Kind regards > Karl Heinz > > > After just seeing that and levaing an angry comment, I was about > > to cancel this mail. However, I just decided to still send it but have > > little expectation that it will make any sense... > > > > Best regards > > Jörg > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
