Hi, > - If those changes were essential to a stable release, they should've been > made in the RC branch, to be merged into develop after release, not the > other way around. The fixes to AC were checked into the release branch, the fix to the mobile skin and item render changes were checked into develop. I don't see why it would be otherwise.
The AC were tested by running the collection tests and by running 90 odd other unit tests which showed no issues. The other two fixes I thought important enough to include in the release and both JIRA issues indicated that they were to be included in the release (marked as resolved in 4.12). > - One of the reasons the releases are 'infrequent' is because they are a lot > of work. More frequent releases == less work, there are less changes and less potential regression issues to sort out. Making a release is reasonably easy and there are now scripts to help with tagging and deploying a RC, it's keeping the documentation etc up to date is harder but if you do that as you go along it make it simpler. What needs to be done is someone else take on the role so I'm not the only person who has make a release in recent time, it's a risk to the project if only one person is familiar with the process. > A bit of structure and developer discipline during the release > process will reduce that work load considerably, IMHO. There was no indication that any of those fixes would break anything and they were as reasonably well tested as they could be without running the all the mustella tests. > Also, I believe an second RC should be just another tag on the original RC > branch, not a new branch of develop A new branch is not created for each RC, each RC is just a tag on the release branch. Thanks, Justin
