Then you should have seen that the release build produces two different source distributions...
Andreas On Thu, Dec 29, 2011 at 18:08, Kasun Indrasiri <kasun...@gmail.com> wrote: > > > On Thu, Dec 29, 2011 at 7:02 PM, Andreas Veithen <andreas.veit...@gmail.com> > wrote: >> >> Did you execute a dry-run as explained in [1]? >> > Yeah. The dry-run was successful. >> >> Andreas >> >> [1] http://www.apache.org/dev/publishing-maven-artifacts.html#prepare-poms >> >> On Thu, Dec 29, 2011 at 10:34, Kasun Indrasiri <kasun...@gmail.com> wrote: >> > We have published the 2.1.0-SNAPSHOT artifacts to the repository [1]. >> > So, if everything is ok, we can proceed with the staging of 2.1.0 >> > release. >> > >> > >> > [1] https://repository.apache.org/content/repositories/snapshots/org/apache/synapse/ >> > >> > >> > On Wed, Dec 28, 2011 at 2:27 AM, Andreas Veithen >> > <andreas.veit...@gmail.com> >> > wrote: >> >> >> >> The Axis2 project had the same issue. The problem is that this tends >> >> to become a vicious circle: >> >> - Because releases are not very frequent, they are painful. >> >> - Because releases are painful, they are not very frequent. >> >> - Because releases are not very frequent, people tend to push all >> >> kinds of changes into the release, which creates new difficulties and >> >> further delays the release. >> >> >> >> Here are the ingredients that we used to break out of that vicious >> >> circle (except for the Axis2 Transports project, which is still caught >> >> in that vicious circle): >> >> - Use maven-release-plugin and Nexus to create branches and to perform >> >> releases. This makes the process easier and more reproducible. >> >> - Eliminate as many manual steps from the release procedure as >> >> possible. >> >> - Document the release process, in particular the manual steps that >> >> still need to be performed. >> >> - Use a strategy to maintain the release/maintenance branch(es) that >> >> ensures that all changes are always included in the trunk and that >> >> makes it easy to determine what changes have been merged to the >> >> branch. This avoids unpleasant surprises when doing a new major >> >> release and ensures that the branch created during a major release can >> >> be used later to produce maintenance releases. That in turn helps >> >> increasing the release frequency and allows to refine the release >> >> process. >> >> - Make sure that several people can act (and effectively do act) as >> >> release managers. E.g. since we switched to Nexus, every project >> >> (Axis2, Rampart and Sandesha2) has been released at least once by >> >> Sagara and at least once by myself. >> >> - A frequent problem is that when starting to plan a release, people >> >> wake up and try to put non-critical issues or feature requests on the >> >> critical path for the release (That's what happened with the Axis2 >> >> Transports release). Don't let that happen. Instead tell people that >> >> they should work on these issues after the release and then ask for a >> >> maintenance release once the changes are ready. >> >> >> >> Andreas >> >> >> >> On Tue, Dec 27, 2011 at 15:42, Hiranya Jayathilaka >> >> <hiranya...@gmail.com> >> >> wrote: >> >> > I believe that the main reason for this mess is our poor release >> >> > frequency. >> >> > If we can do a release at least once every 3-4 months, trunk and >> >> > everything >> >> > else will stabilize gradually. Part of my recent efforts with the new >> >> > documentation, integration tests and dependency cleanup was intended >> >> > to >> >> > lay >> >> > a foundation on which we can do quick and frequent releases with >> >> > small >> >> > incremental improvements. This release has been a great learning >> >> > experience >> >> > so far. We are learning where things have gone wrong and are actively >> >> > taking >> >> > action to fix them. >> >> > >> >> > Thanks, >> >> > Hiranya >> >> > >> >> > >> >> > On Tue, Dec 27, 2011 at 7:41 PM, Andreas Veithen >> >> > <andreas.veit...@gmail.com> >> >> > wrote: >> >> >> >> >> >> On Tue, Dec 27, 2011 at 06:02, Hiranya Jayathilaka >> >> >> <hiranya...@gmail.com> >> >> >> wrote: >> >> >> > >> >> >> > >> >> >> > On Tue, Dec 27, 2011 at 4:58 AM, Andreas Veithen >> >> >> > <andreas.veit...@gmail.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> -1 >> >> >> >> >> >> >> >> The Maven artifacts don't meet the requirements for publication >> >> >> >> to >> >> >> >> Maven Central (see [1] and in particular the link to [2]). In >> >> >> >> particular each artifact must be signed. Each artifact must also >> >> >> >> have >> >> >> >> an MD5 checksum (that is not explicitly mentioned in [2] because >> >> >> >> the >> >> >> >> maven-deploy-plugin normally takes care of this). >> >> >> >> >> >> >> >> I'm not even sure if releasing artifacts using the old >> >> >> >> m2-ibiblio-rsync-repository thing is still supported. What is >> >> >> >> sure >> >> >> >> is >> >> >> >> that the only documented way is via Nexus. >> >> >> > >> >> >> > >> >> >> > Can you please explain how that's done? Should we follow the >> >> >> > instructions >> >> >> > on http://www.apache.org/dev/publishing-maven-artifacts.html? >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> There is also a regression with respect to the project branding >> >> >> >> requirements. Apparently the change in r1051752 was never applied >> >> >> >> to >> >> >> >> the trunk and is missing in 2.1.0. >> >> >> > >> >> >> > >> >> >> > No it is available in 2.1. Take a look at the links available on >> >> >> > the >> >> >> > Main >> >> >> > Menu of the site. It's not yet committed to the trunk. But we >> >> >> > still >> >> >> > haven't >> >> >> > merged the new documentation into the trunk. That will be done >> >> >> > pretty >> >> >> > soon. >> >> >> >> >> >> The change not only modifies the links, but also adds a disclaimer >> >> >> related to trademarks. It's not included in 2.1 and if you now >> >> >> replace >> >> >> the documentation on the trunk with the one from the 2.1 branch, it >> >> >> will be definitely lost. Obviously it is easy to add that again, but >> >> >> I'm pretty sure that this will not be the only change that is lost >> >> >> in >> >> >> the process. >> >> >> >> >> >> I would strongly recommend that before continuing with the effort to >> >> >> release 2.1 the project sorts this out and establishes a clear >> >> >> branching strategy to stop that mess. Otherwise the 2.2/3.0 release >> >> >> will be even worse. >> >> >> >> >> >> > Thanks, >> >> >> > Hiranya >> >> >> > >> >> >> >> >> >> >> >> That seems to be a general problem >> >> >> >> in the Synapse project, namely that there is no effective >> >> >> >> strategy >> >> >> >> to >> >> >> >> manage the release branch and to ensure that all relevant changes >> >> >> >> are >> >> >> >> in the trunk. In Axis2/Rampart/Sandesha2 we have eradicated that >> >> >> >> problem by using a consistent (yet simple) strategy to manage the >> >> >> >> release/maintenance branches. >> >> >> >> >> >> >> >> Andreas >> >> >> >> >> >> >> >> [1] http://www.apache.org/dev/publishing-maven-artifacts.html >> >> >> >> [2] >> >> >> >> >> >> >> >> >> >> >> >> https://docs.sonatype.org/display/Repository/Central+Sync+Requirements >> >> >> >> >> >> >> >> On Mon, Dec 26, 2011 at 16:30, Kasun Indrasiri >> >> >> >> <kasun...@gmail.com> >> >> >> >> wrote: >> >> >> >> > Hi Devs, >> >> >> >> > >> >> >> >> > This is the call for votes to release Apache Synapse-2.1.0. >> >> >> >> > >> >> >> >> > Please review the signed artifacts: >> >> >> >> > http://people.apache.org/~kasun/synapse/2.1-RC1/artifacts/ >> >> >> >> > >> >> >> >> > The m2 repository is available at: >> >> >> >> > http://people.apache.org/~kasun/synapse/2.1-RC1/m2_repo/ >> >> >> >> > >> >> >> >> > Revamped site for this release is available at: >> >> >> >> > http://people.apache.org/~kasun/synapse/2.1-RC1/site/ >> >> >> >> > >> >> >> >> > SVN Info: >> >> >> >> > revision is 1222784 on >> >> >> >> > https://svn.apache.org/repos/asf/synapse/branches/2.1 >> >> >> >> > >> >> >> >> > Here is my +1 to declaring the above dist as Synapse-2.1.0. >> >> >> >> > >> >> >> >> > Thanks, >> >> >> >> > -- >> >> >> >> > Kasun Indrasiri >> >> >> >> > Associate Technical Lead, >> >> >> >> > WSO2 Inc. - "Lean . Enterprise . Middleware" - >> >> >> >> > http://www.wso2.com/ >> >> >> >> > Blog : http://kasunpanorama.blogspot.com/ >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> >> >> >> For additional commands, e-mail: dev-h...@synapse.apache.org >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Hiranya Jayathilaka >> >> >> > Associate Technical Lead; >> >> >> > WSO2 Inc.; http://wso2.org >> >> >> > E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >> >> >> > Blog: http://techfeast-hiranya.blogspot.com >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> >> >> For additional commands, e-mail: dev-h...@synapse.apache.org >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Hiranya Jayathilaka >> >> > Associate Technical Lead; >> >> > WSO2 Inc.; http://wso2.org >> >> > E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >> >> > Blog: http://techfeast-hiranya.blogspot.com >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> >> For additional commands, e-mail: dev-h...@synapse.apache.org >> >> >> > >> > >> > >> > -- >> > Kasun Indrasiri >> > Associate Technical Lead, >> > WSO2 Inc. - "Lean . Enterprise . Middleware" - http://www.wso2.com/ >> > Blog : http://kasunpanorama.blogspot.com/ >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> For additional commands, e-mail: dev-h...@synapse.apache.org >> > > > > -- > Kasun Indrasiri > Associate Technical Lead, > WSO2 Inc. - "Lean . Enterprise . Middleware" - http://www.wso2.com/ > Blog : http://kasunpanorama.blogspot.com/ > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
