[CREATE] Release Timetable

Craig Bradney cbradney at zip.com.au
Fri Oct 14 13:13:26 PDT 2005


On Friday 14 October 2005 16:39, Alexandre Prokoudine wrote:
> Sorry for being silent. Internet connection at my new apartment will
> appear only tomorrow and I don't have much time for reading gmail at
> work :(
>
> On 10/14/05, Jon Phillips <jon at rejon.org> wrote:
> > > > > I've just built Krita 1.4.2 and I'd like those colour palettes(
> > > > > erm, sets, swatches.. ugh).. and either we copy them over to
> > > > > Scribus 1.3.2cvs at some point, or will there be a release of a
> > > > > compiled set of palettes/brushes etc in the near future?
>
> Please don't duplicate. Let's have a release first :)
>
> > > > Right, lets do this for the 0.01 release. Or, should we use this
> > > > numbering scheme: 0.1.0. I think I would like to try this scheme as
> > > > we can climb versions faster.
> > >
> > > 0.1.0 for sure. Despite a lot of people being aware of the version
> > > number doesnt matter, the syndrome of anything not actually reaching a
> > > 1.0 release exists.
>
> Yes, 0.1.0 would be better.
>
> Roadmap needs updates. We actually need agreeement of following topics:
>
> 1. The name or root directory. Should we simply count pro/contra
> voices for each?
>
> 2. Which exactly resources do we package? E.g. there are at least 4
> color swatches files that are not included anywhere: Ubuntu palette,
> KDE palette, GNOME HIG palette and the newest shiny Tango palette.
>
> We need a reasonable decision about Cinepaint/GIMP similar resources
> withe their bit depth difference (sorry about bringing this
> potentially flaming topic back to life).
>
> I'm about to have plenty of spare time this weekend to sit down and
> merge available resources into one root directory with some sexy
> placeholder name and upload it for you :) Anyone, jbjections?

Unless its changed, Scribus includes the Gnome one. Either you indicate the 
depth of the colours in the file (which breaks the "dumb list of data" idea 
that the current palette files follow) , or split it by directory.

> 3. How we package release. I suggest packaging a tar.bz2 with a signature.
>
> 4. How we let packagers from FC/SuSE/Mandrake/Gentoo/Debian/Ubuntu
> etc. know about release.
>
> 5. Whether we upload their packages as well.
>
> > > Scons? Those who know python might jump into this quickly. It looks
> > > fairly simple to someone who doesnt know much python. Then again, a
> > > simple Makefile isnt too bad either, as long as you avoid autotools. :)
>
> Both scons and makefile w/o autocrap is fine with me. Anyone, objections?

Either is fine for me, as long as autotools as avoided :)
>
> 6. Who will create Windows installer?
>
> > Yeah, does anyone want to build a Makefile to pull together our specs
> > (please beat me to it). I don't see any reason for using autotools, as
> > we are not really building cross-platform code, bur rather shared media
> > and standards.
> >
> > Maybe we should have:
> >
> > /usr/share/XXXX/standards or
> >
> > /usr/share/XXXX/specs or
> >
> > /usr/share/XXXX/docs
>
> /usr/share/docs/XXXX-$VERSION

Why do we app programmers have to hack around versions? Just nuke the old 
stuff and move on..

Craig


More information about the CREATE mailing list