I agree having hard targets can create more problems than it solves for a open source project though having internal targets may always be useful to give us something to aim for.
Right now getting a new release is not a priority for Cray/YarcData, we just shipped a release using 2.7.3 and none of the issues uncovered/fixed then are in components we use or are serious enough to be an issue for us right now. The only thing we will likely want to pick up for the next release is the changes I've been experimenting with for TSV/CSV boolean results but that's pretty minor and isn't something that is a problem for any users right now. Regardless we'll almost certainly take a new release as soon as it is available so we can start testing it in our stack and ensure it doesn't cause us any problems. We primarily only use ARQ/Jena (we dropped Fuseki a while ago) which hasn't changed that much so we don't anticipate any problems with adopting the next release Rob On 10/4/12 1:04 PM, "Andy Seaborne" <[email protected]> wrote: >On 04/10/12 20:28, Rob Vesse wrote: >> Andy >> >> >> Is it worthwhile for us as a PMC to try to adopt a planned regular >>release >> cycle? >> >> This could either be dates when we aim to produce a new release e.g. 1st >> of the month each quarter or it could just be a general aim of a new >> release within N months of the previous release e.g. 3 months after the >> previous release. >> >> The latter might be a better option for us as it gives us the >>flexibility >> to make a new release sooner if there are important changes/fixes we >>want >> to get out to users but also gives users some guarantee of when to >>expect >> a new release. >> >> Now there may be times when we can't meet the target because we have >>less >> time to devote to the project, larger refactors/new features may require >> more significant testing and hardening periods etc. but it might be nice >> for us to aim to do this. > >Yes - a good discussion to have including what the general release >criteria are. > >Also, I thought the community testing of SDB went rather well. Calling >a release, getting reports before having to freeze for the vote is a >good thing. We can keep the vote to 3 days. A long vote seems to gain >us little. > >In past life the target was once every 6 months but that was for the >more stable bit. As we need to start removing old stuff (e.g. DAML+OIL, >bulk update handlers, ...) > >Maybe 3? 4? months? > >But it can be too frequent. Many users will not be upgrading each time >(not unreasonably). > >It's becoming like Ubuntu LTS and normal releases. > >What works for Cray? > >We won't always make it - that's for sure. It's a tricky balance to >even mention plans because if you meet the tick point a couple of times >it becomes "expected" :-) Open source projects just seem to have demand >exceeding supply. > >I suggested a 2.7.4 release now to sync with SDB ... thoughts? My worry >there was consuming PMC and interested parties bandwidth (I'd have added >LARQ as well as it is incubator'ed but it adds work for us all). > > > Andy > > >> >> Rob >> >> On 10/4/12 12:19 PM, "Andy Seaborne" <[email protected]> wrote: >
