--
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/-/Xpwg9tIt2xAJ.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
--
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/-/Xpwg9tIt2xAJ.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
-foca
- Prem
In general I agree that tiny version releases should not need release candidate gems. On the flip side, I appreciate that core is making an effort to warn upfront too and I think the RC process has value. In my case, it is easy to automate my tests on that git tag or a bundled download.
- Ken
Versioning software can be a bureaucratic nightmare. It
can also be a swamp in which no-one knows exactly what it
means. To avoid the latter without advocating the former
I think it is reasonable to have some idea of what the
core team presently hold as sufficient cause to change
each of the Major, the Minor and the Patch numbers for
RoR. Is there a guide to this criteria somewhere?
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:Byr...@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
Rails 3.1.2.rc2 just got released. Around the time of the 3.1.1 release, there was also a relatively evolved release process including announcements and release candidates.Why?
In other words, bugfix releases are cheap. Why waste time with release candidates when we can just get 3.1.2 right away? Then, every fix that would otherwise be made between 3.1.2.rc2-3.1.2 can just be released as 3.1.3.
Pushing a candidate is part of making that process robust and repeatable.
The candidates are to avoid release screwups, not to capture every last possible bug. (3.1.2.rc1, for example.)
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.
--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
But in general, doing releases is a big hassle. Therefore, I would
prefer to encounter this hassle on my own schedule, not in the middle of
the night when I've just messed up a 'real' release and am racing
against the clock to push out a fixed one.
Agreed. People complained when we didn't have rc's, now they complain
that we do. ;-)
I prefer to stick with the cautious route and release RCs. It seems to
be working well so far.
--
Aaron Patterson
http://tenderlovemaking.com/