Hi All, This is a very good question. Lets discuss these options so we are consistent across releases.
If we look at the way we are doing releases, we are calling a feature freeze and code freeze and cutting a release. Most of the time, our build is broken. Jenkins statistics for Airavata is not looking good at all [1]. We are barely fixing the build a day before the release, putting out an RC and testing on it and releasing it in a quick succession. As we are seeing on user lists, we have users upgrading with every release. I think we should increase the release quality. I would vote for atleast 3 RC’s per release. If we are not finding issues in first RC, I would say, either the software has magically become too too good or we are not doing through testing. I suspect the later. I will propose the following, please counter it and lets agree on a process: * Lets post a RC1 as is (which means it will have a snapshot). This pack, we should all test as much as possible, so its more of a test candidate then a release candidate. If it helps, we can use the name TC1. I am not particular on the naming but trying to emphasize the need for having atleast more RC's per release. * If we do not expose significant issues in RC/TC 1 then we proceed with RC2 which will follow the proper release process. But if we have a reasonable issues bought out, we need a RC2/TC2 also without following the release process. * The key thing I am proposing is, we keep doing RC/TC’s until we all are sure the quality is good enough with documented known issues. When we are sure, then we proceed to have RC with proper release process. So this will mean more testing and twice (or more) the times every one has to test, but I think it is worth it. This might also get over the 6 week release cycle, but I think we need to trade for some quality releases as we march towards 1.0. Suresh [1] - https://builds.apache.org/job/Apache%20Airavata/ On Dec 15, 2013, at 4:28 PM, Lahiru Gunathilake <glah...@gmail.com> wrote: > > Hi Chathuri, > > I think having snapshot as the version in RC is wrong. Every RC has to be > like a release and if it pass we just call a vote/discussion thread and do > the release. If we do with snapshot and if things go right, then have to > change versions and test again. But we can do the release just by changing > snapshot without testing but that wrong AFAIT. > > I remember doing this mistake in earlier release with RC1 build. I think we > can stick to the release management instructions in airavata.org. > > Regards > Lahiru > > > On Fri, Dec 13, 2013 at 3:43 PM, Chathuri Wimalasena <kamalas...@gmail.com> > wrote: > Hi All, > > Airavata 0.11 RC1[1] is ready for testing. > > Here are some pointers for testing > • Verify the fixed issue for this release [2] > • Verify the basic workflow composition/execution/monitoring scenarios > from > • Airavata 5 & 10 min tutorials [3],[4] > • Verify airavata client samples > • Verify the stability with derby & mysql backend databases > • Verify that the XBaya JNLP distribution works > • Verify deploying Airavata server in a tomcat distribution > Please report any issues[5] if you encounter while testing. Thank you for > your time in validating the release. > > Regards, > Chathuri (On behalf of Airavata PMC) > > [1] https://dist.apache.org/repos/dist/dev/airavata/0.11/RC1/ > [2] > https://issues.apache.org/jira/browse/AIRAVATA-278?jql=project%20%3D%20AIRAVATA%20AND%20fixVersion%20%3D%20%220.11%22%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC > [3] > http://airavata.apache.org/documentation/tutorials/airavata-in-5-minutes.html > [4] > http://airavata.apache.org/documentation/tutorials/airavata-in-10-minutes.html > [5] https://issues.apache.org/jira/browse/AIRAVATA > > > > > > > -- > System Analyst Programmer > PTI Lab > Indiana University
