Dan, +1 for your list of goals
I do have 1 tiny commit, but I think that we could satisfy #4. Our database was started in the 1.6 days and has encountered problems at pretty much every upgrade which makes it good to test against in my opinion. Also, Blake is new to the upgrade process so a fresh set of eyes might do some good.
Regards, Justin On Wed Oct 16 11:01:23 2013, Dan Wells wrote:
Hello all, I am pleased to announce that Evergreen 2.5-rc1 is now available for download. Once again, thank you to the many folks who put in some extra time to help us get to this point! You can grab RC1 from the downloads page here: _http://evergreen-ils.org/egdownloads/_ Given the relatively short timeframe, the RC period was a bit busier than expected. In all, 22 bugs were committed in the (roughly) two weeks since beta1, which you can see here: _https://launchpad.net/evergreen/+milestone/2.5.0-rc_ My site installed an early cut of the RC upgrade on Friday, and after a few hiccups (which have since been fixed), things are going smoothly. So, now that RC1 has landed, how do we get from here to a final 2.5.0? Until now, I have been setting fairly arbitrary deadlines for milestones, but as the needs of these last few milestones have become less fluid, selecting target dates has become a little more futile. For 2.5.0, I’d like to try something a bit different. Basically, I am proposing that we use a checklist of specific goals, and when we meet every goal, then 2.5.0 final will be cut. Here are the goals I have in mind: 1. At least two sites do a clean install of 2.5-rc1 from the release tarball 2. At least one site upgrades a production database (or exact clone) to 2.5-rc1 using the release tarball upgrade script 3. At least one additional site upgrades to 2.5-rc1 (code and DB, production or testing) from the release tarball 4. At least one site managed by a non-committer either installs or upgrades to 2.5-rc1 The reason these goals specify using the release tarball is because we want to validate not only the code, but the release process. I should also note that it’s possible that the event which satisfies goal 4 will at least partially satisfy one of the first three. Overall, what do we think about these goals as a benchmark for release? Too much? Not enough? Please reply if you have any feedback on this idea! Finally, as far as bug management, I have created two new milestones, both 2.5.0 and 2.5.1. Since the ideal situation for release will be to make as few changes as possible for 2.5.0, I have moved all but one bug to 2.5.1. If you think there are things in the 2.5.1 list which are critical for 2.5.0, please do make a case for them, but also please keep in mind that if too many changes get applied to 2.5.0, we may need to release it as RC2 and try the process again. As always, feedback is welcome. Thanks, Dan Daniel Wells Library Programmer/Analyst Hekman Library, Calvin College 616.526.7133
