Re: OPIE 1.2.3 release?
Paul Sokolovsky <[email protected]> Wed, 24 Jan 2007 00:00:03 +0200
| Newsgroups | gmane.comp.handhelds.opie.devel |
|---|---|
| Message-ID | <[email protected]> |
Hello Erik, Tuesday, January 23, 2007, 9:02:27 PM, you wrote: > On Tue, Jan 23, 2007 at 08:18:21PM +0200, Paul Sokolovsky wrote: >> Hello Erik, >> >> Tuesday, January 23, 2007, 7:36:58 PM, you wrote: >> >> > On Tue, Jan 23, 2007 at 04:01:16PM +0100, Marcin Juszkiewicz wrote: >> >> > I could be convinced to do a 1.2.3 release soon. What is your timetable >> >> > for a new OZ release? >> >> >> >> First test images at ~3 February, then few test releases and final release >> >> in March or begin of April. >> >> > OK. I will attempt to get ready to tag next week. Opie devs - we are >> > heading for a freeze on 2007-01-29. Please work towards that. >> >> This is very, very early. We started with question if there any >> dates for release at all, and now it's like it's next week. > Considering that except for Paul E's fixes the rest are one liners to > deal with minor annoyances in often dusty corner cases I think a point > release is not that hard to come up with. And I would like to see a > point release soon just to capture that stuff. > I don't think that a point release now is a big deal. It just sets us up > for another one in a few months. And that's exactly a concern - too hasty a release now, with some things omitted, and then long wait for next chance to add them. I myself first of all concerned with machine support in OPIE - there're few patches fly around adding this or that machine, or BT support, or something like, and it would be nice to collect them. And actually, it may be just good idea to add machine IDs for all ports maintained in HH.org CVS, plus maybe some active outside ports. >> >> I guess, if it's ok to do release soon (like in 3-4 weeks), let's >> make call for patch submission of the scope suitable for the freeze >> (like adding new machines/elaborating existing, and small build&usability >> fixes). Marcin could use dated builds for 1-2 initial OZ test releases, >> and later have tag (or branch?) made. > I am more then willing to compromise or even back off completely on an > impending freeze. If Paul E and Dan Williams speak up I am sure we can > reach a decision. > I realize that making that broad statement is heavy handed. Let me know > what you all would prefer to do. > I don't think that we need to be as formal about a release as you > mention. But I am all for applying process to a release. It makes for a > more solid product even if it might take a while. My concern is just like above - if OPIE was barely maintained for several months, it would be nice to give people more time to submit patches for next release. And, about release procedure - I wanted to write separate RFC, but just can't find enough time now. So, quick brain-dump: what about making subreleases for individual OPIE apps, if they undergo some useful changes. Such subreleases might use 4th version component, like libopie2-1.2.2.1. Having such releases would help distros to ship updated OPIE applications sooner (without risk of using "unstable" stuff), and that would be helpful, unless there's going to be short cycles for main releases, which we probably shouldn't count for. > E -- Best regards, Paul mailto:[email protected] _______________________________________________ http://opie.handhelds.org/cgi-bin/moin.cgi/DeveloperWikiIndex Opie-devel mailing list [email protected] https://handhelds.org/mailman/listinfo/opie-devel