On Wed, Apr 03, 2013 at 02:08:42PM -0500, Krzysztof Parzyszek wrote:> On 4/2/2013 11:51 AM, Tom Stellard wrote: > > > >I would really like to see the LLVM project start to make official bug fix > >releases (e.g. 3.3.1, 3.3.2, etc.). I think that this would be useful for a > >lot of the users of LLVM, especially projects that use LLVM as a library. > > Does this really make sense with a 6 month release cycle for the > main releases? Who are the customers who would be able to request a > dot release?I don't think the length of the release cycle really matters too much. The main point of having dot releases is so that projects that depend on LLVM can ship their own stable releases that are based on a stable version of LLVM. As it stands now projects either have to use a released version of LLVM and just accept whatever bugs come with it or they need to go back and update their own stable versions (which makes them not so stable) each time there is a new LLVM release.> Each additional bugfix release carries a significant cost. Who is > going to be investigating bugs in prior releases, especially if the > problem can no longer be reproduced with the development branch? >If someone cares enough about a bug, then they should be willing to spend the time investigating it. -Tom> -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Krzysztof Parzyszek
2013-Apr-03 19:51 UTC
[LLVMdev] RFC: Bug fix releases for 3.3 and beyond
On 4/3/2013 2:36 PM, Tom Stellard wrote:> > I don't think the length of the release cycle really matters too much.It does. Someone has to do the work---the effort goes to either to the ongoing development or to the maintenance releases. A short release cycle generally means less "free time" in the main development. Also, if the maintenance release goes out of service when a main release is made, then the users may still be forced to switch---the shorter the release cycle, the more likely this is to happen. How many customers out there are shipping their LLVM-based products without actually including the LLVM sources? If they do include the sources, they may fix the bug locally, especially if they are capable of investigating what the problem is. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Wed, Apr 03, 2013 at 02:51:05PM -0500, Krzysztof Parzyszek wrote:> On 4/3/2013 2:36 PM, Tom Stellard wrote: > > > >I don't think the length of the release cycle really matters too much. > > It does. Someone has to do the work---the effort goes to either to > the ongoing development or to the maintenance releases. A short > release cycle generally means less "free time" in the main > development. Also, if the maintenance release goes out of service > when a main release is made, then the users may still be forced to > switch---the shorter the release cycle, the more likely this is to > happen. >I understand this. The point I was trying to make was that regardless of the length of the development cycle, it is still necessary to have dot releases.> How many customers out there are shipping their LLVM-based products > without actually including the LLVM sources? If they do include the > sources, they may fix the bug locally, especially if they are > capable of investigating what the problem is. >Projects that wants to be distributed as part of a Linux or *BSD distribution really can't ship their own custom version of LLVM with their project. They need to use the LLVM version that is provided by distributions, so this rules out this kind of solution. Also, I think it is in the LLVM project's best interest to encourage users to contribute bug fixes back to the project. If projects are required to maintain their own bug fix versions of LLVM, then they have little incentive to contribute the fixes back. -Tom