On Tuesday, November 15, 2011 4:26:34 PM UTC+1, Jeremy Kemper wrote: > > > Pushing a candidate is part of making that process robust and repeatable. >
It's bizarre that pushing *more* releases makes the act of pushing releases easier. The candidates are to avoid release screwups, not to capture every last > possible bug. (3.1.2.rc1, for example.) > I can understand why the core team tries to avoid the scenario that once led to releasing 2.3.6 + 2.3.7 + 2.3.8 in the same day. That day, developers didn't feel to confident about those releases because first two were "screwups". But maybe there are ways to improve the release process and detect "screwups" early before pushing the actual gems out. That would eliminate the need for throwaway version numbers (i.e. RCs for patch releases). I don't have concrete suggestions about this due to my lack of experience for releasing software at this scale. @everyone: This discussion is not about should Rails follow SemVer for their versioning policy. But Rails patch releases already conform to SemVer in a way they don't introduce/change features. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/tJpAHzrIGewJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
