Hi Alec, Is "export/share to ics" an adequate data upgrade path if we're going to be pushing the latest and greatest? You'll have to go find the tickets for your shared collections, and your Cosmo password, too.
Maybe it actually wouldn't be too tricky to write a script that automatically exported collections to ics, sucked out collection URLs and settings, backed up the old repository, installed the next Chandler and imported the ics files and collections. If we're OK with asking people to do this manually, or Phillip plans on writing something to automate this in the near term, then I agree, lets use our pre-1.0 status to get the most useful feedback we can. Sincerely, Jeffrey Alec Flett wrote: > Sheila Mooney wrote: >> + We would NOT create a new landing page for each milestone, we would >> use the existing 0.6 landing page. > +1 >> + We would not update the release number or download link on the >> existing 0.6 landing page. It's still possible we will have further >> patches to 0.6 and this would just get confusing. > -1 > > As we are still a pre-1.0 product, I think the point of these mini > releases (from both an internal and external perspective) is that this > (the mini release) is what we want users playing with. Encouraging > people to download and give us feedback on 0.6 is really going to be > fairly unhelpful. Personally, I think whenever 0.7 alpha 1 or whatever > it is called goes out the door, we stop trying to deal with 0.6. > > I may be wrong here, but I think part of the "release more often" tenet > includes "obsolete old releases faster" - it was positively > embarrassing, especially during the last few weeks of the 0.6 release, > to send friends/collegues/etc to the download site for chandler only to > have them download the woefully outdated, 6-month old 0.5. > > Obviously when we're past 1.0, this situation changes dramatically. At > that point we should start keeping links to the latest "stable" > releases, indicating that newer builds are merely experimental, etc.. > But we're not there yet. All of our builds are experimental. Some are > just less experimental than others. :) >> + The existing readme for 0.6 would NOT be replaced or modified. >> Instead we would have a new simple html page listing the new features >> and known critical bugs, very similar to the milestone report cards >> used in 0.6. >> + The feature list would be brief and not detailed step-by-step >> instructions on how to use any of the new features. >> + A news section (or link) would be added to the current landing page >> with a brief "mini-release" announcement, download links and a link to >> the readme style html page. >> + This news section could be simply a new button on the left nav. >> + We would not have demos, screen shots etc. >> + Announcements would be sent to the list and put in the blog. >> + We would not expect any supporting developer documentation. >> > +1 to all of this, except maybe a global search 'n replace of "0.6" with > "0.7 alpha 1" - keeping in line with my feelings about obsoleting 0.6 as > soon as possible... > > Alec > >> Please reply to the list with any thoughts, comments, concerns or >> suggestions. >> >> Thanks, >> Sheila >> >> >> >> >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> >> Open Source Applications Foundation "Dev" mailing list >> http://lists.osafoundation.org/mailman/listinfo/dev > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > Open Source Applications Foundation "Dev" mailing list > http://lists.osafoundation.org/mailman/listinfo/dev _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
