On Jun 1, 2013, at 3:55 PM, "Dennis E. Hamilton" <dennis.hamil...@acm.org> wrote:
> > +1 > > The <version>-specific path on the site is also a fine way to locate the > check-for-update target, since the release has its release <version>. It can > also have human-readable (and localized) pages that provide update > information to someone who visits on-line. > > The default page at those locations could provide anything important about > those particular versions, including obsolescence by security updates, what > release replaced it, how to still obtain it, etc. > Good point, especially if there is access via the Help menu or other prominent place in the UI. It is a good way to reach out to our users. If we had it with 3.4.1, for example, we could have added updated information for things like the language updates or fixes for the profile-related problems. A strong form of online engagement with our users could be quite powerful. Although we had 50 million downloads of AOO 3.4, engaged users via the announcement list, Facebook, Twitter, etc., is only around 15,000 users. Imagine if all 50 million had one click access to the latest info on their installed AOO release? -Rob > - Dennis > > > -----Original Message----- > From: Rob Weir [mailto:rabas...@gmail.com] > Sent: Saturday, June 1, 2013 08:55 AM > To: dev@openoffice.apache.org > Subject: Re: [RELEASE][TRANSLATION]: changes to the README file for 4.0 > > [ ... ] > > Crazy idea. What if we just made a sub domain for each release? Or > equivalently a path under ooo-site. Then we could have hard-coded > standard paths in the code and other systems like: > > > www.openoffice.org/release/<version>/README > > Could also do LICENSE, release notes, even the update notification XML files > > So a special website per release. Then when we do a new release we > just do an svn copy to populate the new site, and update as needed. > The code then points to appropriate dir based on build time version > flag. > > -Rob > > > >>> 2) The README has many references to the Solaris platform, which is >>> not supported in the release. Should that be migrated into a separate >>> readme that would be distributed by the Solaris port? >> >> The Solaris-specific strings are not displayed on other operating systems >> (you will see CSS classes that are used to suppress them at the above URL). >> That said, they are probably outdated and irrelevant indeed. I didn't move >> strings since it might have had an impact on translation. >> >> Regards, >> Andrea. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
