[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: 2.0 or 2.0RC2 and when ?
From: Cyrille Berger <cberger () cberger ! net>
Date: 2009-04-17 11:01:29
Message-ID: 200904171301.29508.cberger () cberger ! net
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Friday 17 April 2009, Thomas Zander wrote:
> On Friday 17. April 2009 11:52:05 Jaroslaw Staniek wrote:
> > Given that Kexi wil lenjoy some more weeks/months of Alpha/Beta
> > development, I am wondering how to provide tarballs for packagers to
> > package the app early enough.
>
> That would be exactly the same as any other KOffice2.1 application.
I don't intend to have alpha release of koffice 2.1, past experiences by us
(wether 1.6 alphas, or 2.0 alphas), or by other (KDE has also dropped their
alphas) have shown the limited interest for this kind of release, when it
comes to testing. For the 2.0 alphas, they were mostly a "marketing" tool to
show that KOffice was still alive, and is progressing. For 2.1 we don't need
that anymore, since the release of 2.1 will come "soon", and we will keep the
marketing noise with the maintenance releases of 2.0.x.
So that leave testers, most of the early testers tends to build directly from
trunk, since while packages are nice, most people would prefer to have the
stable version for real work and the dev version for playing, and usually you
can have one package but not the other.
So that mean we want to make compiling KOffice easy, in my opinion, that
involves:
* Making sure that [1] is up-to-date when it comes to dependencies, and if
someone has a problem update the documentation
* Make sure the dependencies are easilly installable for most people in most
distributions with little effort
* Optionnaly, we can have a tag, corresponding to a revision of koffice/trunk
that is known to compile (from a clean dir), which can be pointed to
distributions that want to offer a trunk package (we can also make a tarball
from that tag), but we need a volunteer to take care of that tag
[1] http://wiki.koffice.org/index.php?title=Building/Building_KOffice
--
Cyrille Berger
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" \
"http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" \
content="1" /><style type="text/css">p, li { white-space: pre-wrap; \
}</style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt; \
font-weight:400; font-style:normal;">On Friday 17 April 2009, Thomas Zander \
wrote:<br> > On Friday 17. April 2009 11:52:05 Jaroslaw Staniek wrote:<br>
> > Given that Kexi wil lenjoy some more weeks/months of Alpha/Beta<br>
> > development, I am wondering how to provide tarballs for packagers to<br>
> > package the app early enough.<br>
><br>
> That would be exactly the same as any other KOffice2.1 application.<br>
I don't intend to have alpha release of koffice 2.1, past experiences by us (wether \
1.6 alphas, or 2.0 alphas), or by other (KDE has also dropped their alphas) have \
shown the limited interest for this kind of release, when it comes to testing. For \
the 2.0 alphas, they were mostly a "marketing" tool to show that KOffice was still \
alive, and is progressing. For 2.1 we don't need that anymore, since the release of \
2.1 will come "soon", and we will keep the marketing noise with the maintenance \
releases of 2.0.x.<br> <p style="-qt-paragraph-type:empty; margin-top:0px; \
margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; \
text-indent:0px; -qt-user-state:0;"><br></p>So that leave testers, most of the early \
testers tends to build directly from trunk, since while packages are nice, most \
people would prefer to have the stable version for real work and the dev version for \
playing, and usually you can have one package but not the other.<br> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>So \
that mean we want to make compiling KOffice easy, in my opinion, that \
involves:<br>
* Making sure that [1] is up-to-date when it comes to dependencies, and if someone \
has a problem update the documentation<br>
* Make sure the dependencies are easilly installable for most people in most \
distributions with little effort<br>
* Optionnaly, we can have a tag, corresponding to a revision of koffice/trunk that is \
known to compile (from a clean dir), which can be pointed to distributions that want \
to offer a trunk package (we can also make a tarball from that tag), but we need a \
volunteer to take care of that tag<br> <p style="-qt-paragraph-type:empty; \
margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; \
-qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>[1] \
http://wiki.koffice.org/index.php?title=Building/Building_KOffice<br>
-- <br>
Cyrille Berger</p></body></html>
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic