Hi, The Writer can link text frames. This functionality would be greatly appreciated if it worked also in the Draw.
Luiz Oliveira Em 28-04-2012 21:30, Rob Weir escreveu: > On Sat, Apr 28, 2012 at 4:07 PM, Pedro Giffuni <[email protected]> wrote: >> Hello; >> >> >> On 04/28/12 11:32, Rob Weir wrote: >>> I'm already starting to get questions on what we'll be doing after AOO >>> 3.4 is released. Based on previous conversations on this list, I'm >>> able to speak confidently about a few things: >>> >>> 1) We'll probably graduate to a Top Level Project >>> >>> 2) IBM says they will contribute Symphony source code after 3.4 is >>> released >>> >>> 3) We have some initial feature ideas for AOO 4.0 on the wiki: >>> >>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Feature+Planning >>> >>> 4) We also have some ideas listed for an AOO 4.1: >>> >>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Feature+Planning >>> >>> Beyond that, do we have anything to say? >> >> Well, we have to integrate some CWSs. I am interested in gnumake4 >> since it might help clean some issues in the BSD port. For the rest >> I am not sure what is there or how stable it is so I would guess >> we should tackle them slowly and leave most of them for "later". >> >> We also have to update some components. Anything with an Apache >> tag on it, like Apache Commons or Apache Lucene comes first >> because working with other Apache projects is key for our >> graduation. Some other components are important but involve a lot >> of hard work: It would be really great if someone from ICU would >> give a hand too. >> >> The clang port is also rather important and would help the MacOSX >> support. >> >> Finally, I think we should continue cleaning/replacing some Category-B >> software. For example, carrying an outdated version of Mozilla SeaMonkey >> just for addressbook support, is a nonsense. >> >> All in all, I think we should focus on stability and not on features. >> > So these (to me) sound more like items for a 3.5 than a 3.4.1. > > Here's how I see things, based on my experience with commercial > software development: > > 1) We want to have a maintenance branch that can be used to deliver > quick-turnaround releases. This would be in case we receive reports > of a security vulnerability, or a new critical bug, or maybe something > that breaks in us due to a platform update. In other words, things we > need to react to quickly. > > In order to turn around a maintenance release quickly we need to limit > changes. We don't have betas for these releases. We might require > code reviews. We test changes and "test around" changes, but we > might not have a full test cycle. The documentation does not change. > > We might make very limited feature additions, if they can be made > without requiring core code changes. For example, adding a new > language is general safe, since the test effort is limited to that > language. You cannot break existing 3.4 functionality by adding a new > language. > > 2) We also want feature release, like 3.5, 3.6, etc. Almost anything > can go into them. They might have beta release. They would have full > test cycles. They would require all translations to be updated. > Documentation would need to be updated as well. > > 3) Then we have major updates, like 4.0. These are similar to #2, > only more substantial. > > Was there a similar distinction made in OOo? > > -Rob > >> Just my $0.02. >> >> Pedro. >>
