Re: [Tracker] Releasing 0.7 Next Week

[Jamie McCracken <jamie mccrack googlemail com>]

On Tue, 2009-09-22 at 08:15 +0100, Martyn Russell wrote:
> On 22/09/09 04:23, Jamie McCracken wrote:
> > How would you feel about delaying release until end of next week? I know
> > we are desperate to get something out of the door but I feel an extra
> > week will allow us to release something thats more polished
>
> This is the 3rd week we have put things off. So I don't think we should.
>
> > I suggest going into feature freeze end of this week and spend all of
> > next week fixing bugs prior to the release (there are quite a few
> > annoying bugs especially in rdf classes)
>
> This is what we will be doing after the 0.7 release. People will know it 
> is an unstable release and that we will be releasing often with fixes.
>
> > We should be mindful that a release will also break a lot of existing
> > apps (nautilus and file chooser spring to mind). I dont know if anyone
> > has time to fix those? If not we will need to state clearly what apps
> > are broken in the release notes
>
> Well, apps don't _HAVE_ to upgrade yet. Also we have been fixing 
> nautilus and the file chooser already. I think JÃrg has finished that 
> now right JÃrg?

if they are fixed then yes I agree we can release end of this week

the fix needs to be backwards compatible though with tracker 0.6  and
pushed upstream

> > Its also imperative that an update from 0.6 series to 0.7 series is
> > tested so we can make sure a reindex is forced and preferences are
> > migrated correctly - Im more worried about the upgrade process than
> > anything else as a hell of a lot has changed here
>
> No, this is not true.
>
> There are a number of reasons why.
>
> 1. The config is stored in completely different places and not compatible.
>
> 2. 0.6 and 0.7 _CAN_ co-exist at the same time, that's how it has been 
> designed.
>
> 3. A fresh index will happen anyway because the database names have 
> changed too - so old and new dbs can exist in the same place.


what Im saying is we need to move over the old config if possible so
that its a smooth upgrade.

> --
>
> The only consideration here, is if we should port the config to the new 
> config and we could do that with some script I suppose.