openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janI <j...@apache.org>
Subject Re: [DEVTOOLS] [PROPOSAL] branch Netbeans plugin for 3.0 and begin 4.0 trunk
Date Mon, 15 Apr 2013 12:12:35 GMT
On 15 April 2013 11:22, J├╝rgen Schmidt <jogischmidt@gmail.com> wrote:

> On 4/15/13 9:42 AM, janI wrote:
> > On 15 April 2013 00:23, Carl Marcum <cmarcum@apache.org> wrote:
> >
> >> Hi Jan,
> >>
> >>
> >> On 04/14/2013 02:58 PM, janI wrote:
> >>
> >>> On 14 April 2013 20:25, Carl Marcum <cmarcum@apache.org> wrote:
> >>>
> >>>  Hi Juergen,
> >>>>
> >>>>
> >>>> On 04/14/2013 01:32 PM, Juergen Schmidt wrote:
> >>>>
> >>>>  Hi Carl,
> >>>>>
> >>>>>
> >>>>> Am Sonntag, 14. April 2013 um 19:23 schrieb Carl Marcum:
> >>>>>
> >>>>>   On 02/10/2013 04:11 PM, Carl Marcum wrote:
> >>>>>
> >>>>>>
> >>>>>>  On 02/10/2013 02:50 PM, Juergen Schmidt wrote:
> >>>>>>>
> >>>>>>>  Am Sonntag, 10. Februar 2013 um 19:04 schrieb Carl Marcum:
> >>>>>>>>
> >>>>>>>>  Hi all,
> >>>>>>>>>
> >>>>>>>>> I would like to branch NB integration plugin for
3.0 and start
> >>>>>>>>> modifying
> >>>>>>>>> trunk for AOO 4.0 compatibility.
> >>>>>>>>>
> >>>>>>>>> I would like to also tag current version as 3.0.1
at the same
> time.
> >>>>>>>>>
> >>>>>>>>> Trunk would become version 4.0 to maintain major
version number
> the
> >>>>>>>>> same
> >>>>>>>>> as AOO.
> >>>>>>>>>
> >>>>>>>>> If there are no objections to the above proposal
within 72-hours
> >>>>>>>>> then
> >>>>>>>>> I
> >>>>>>>>> will invoke Lazy Consensus and proceed to implement
the above
> >>>>>>>>> proposal.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>  You can if course create a branch but I don't see
the demand for
> >>>>>>>> it.
> >>>>>>>> You can continue the development towards 4.0 on trunk.
I don't see
> >>>>>>>> many activity here and a branch is not really necessary
from my
> pov.
> >>>>>>>>
> >>>>>>>> Juergen
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Best regards,
> >>>>>>>>> Carl
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>  I agree. we can always create a branch based on a revision
number
> >>>>>>> later if needed.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> I thought about it more and since the next changes will be
> incompatible
> >>>>>> with AOO 3.4 I tagged a 3.0.2 version and created a 3.0 branch
to
> make
> >>>>>> it easier if someone needs to make changes for 3.4 compatible
> plugins.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>  I agree now and with my upcoming 3layer removal there will
be some
> >>>>> work
> >>>>> to do in the plugin. It mainly that places of jars, tools, libs
have
> >>>>> changed.
> >>>>>
> >>>>> Juergen
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>  Is this something that will be implemented in AOO 4 release?
> >>>>
> >>>>
> >>> How come it is a 3.0 branch ?? that sounds old to me, shouldnt it be
> >>> 3.4.1x branch ?
> >>>
> >>>
> >> The Netbeans plugin versions didn't historically coincide with the OOo
> >> version numbers (that I know of).
> >>
> >> When the code came to Apache it was version 2.0.7 and I tagged that
> >> version and started work to make it run on Netbeans 6.9 which was
> Netbeans
> >> 7.0 api changes. That's when I changed it to 3.0. Some additional
> >> localization work took it to 3.0.2.
> >>
> >> I'm not sure what the best solution to version numbering other than to
> do
> >> a major number change when it's not compatible with AOO or NB and keep a
> >> compatibility table somewhere.
> >>
> >
> > Thanks for clarifying it for me, I am still learning a lot, however I do
> > have some opinion on the version numbering.
> >
> > Netbeans is part of main, and released as an integrated part of AOO. As
> far
> > as I can see it is not available (for download) independent of AOO. If I
> > install AOO 4.0, have a problem and see netbeans is 3.0 I would assume
> that
> > I missed an upgrade. Therefore I will strongly suggest that all modules
> in
> > main get version 4.0.
> >
> > If I am wrong and netbeans are available independent, it should not be in
> > main. Because we will (as we did with 3.4.1) vote about releasing 4.0,
> and
> > then it would not be correct to silently release a new version of
> netbeans,
> > just because it is included.
> >
> > Please do not read my comments as I am against the work. I solely think
> > about the version number logistic, which I want to make as simple as
> > possible.
>
> The NetBeans plugin is a developer tool that uses OpenOffice and SDK and
> depends on a specific version in the future but it can be seen as
> independent and ideally we would bring it back in the plugin center of
> Netbeans directly.
>
> The plugin don't comes with the office and is not part of the source
> release.
>

I thought the source release was the full main ??

Where can I find the script that  generates the source release ?

rgds
jan i.


>
> Juergen
>
> >
> >
> >>
> >>  I do agree with the principle in having a branch. We have however to
> make
> >>> it clear to developers, that when using that branch their code will not
> >>> avalible with 4.0.
> >>>
> >>
> >> I agree, that's why I hope everyone continues to do work on trunk and we
> >> only merge changes if needed for some reason. But we have a well
> >> established break point.
> >>
> >
> > To me, branches should be used for work that goes across many modules
> (like
> > gbuild and l10n), or work that takes a long time (months) to complete.
> But
> > I have no strong opinion if somebody wants to use a branch, and have the
> > pain of merging it later.
> >
> > rgds
> > Jan I.
> >
> >>
> >>
> >>
> >>> rgds
> >>> jan I.
> >>>
> >>>
> >> Best regards,
> >> Carl
> >>
> >>
> >>
> ------------------------------**------------------------------**---------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> dev-unsubscribe@openoffice.apache.org>
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message