jedit-devel Mailing List for jEdit

Hi,

Le Mer 17 juin 2015, à 00:41, Vampire a écrit :
> Well, actually we introduced the current scheme out of two reasons as
> far as I remember.
> 
> 1. to be able to do new development in trunk while the stable version
> can be hardened for release and improved with bugfix versions
> 2. to improve the quality of jEdit by having a 4-eyes-principle for
> changes that make it into the stable version to not introduce bad bugs
> lightly in the stable version
> 
> If it is just about 1., I totally agree that we can just save the
> stable branch and fix bugs in trunk as long as only stuff that would
> be merged into the stable branch anyway is added and then release
> 5.3.1, 5.3.2 and so on from trunk.
> But I think this would not help with "I felt bored when writing
> plugins that uses new api to have to wait the next year to release my
> plugins.".

The "I felt bored when writing plugins ..." was only about the idea of 
having only one release per year in fact, it is a different problem that 
is independent. We can continue or not to have stabilization branches,
but release new features more often than one a year.

> The more important thing is, if we now decide not to follow the
> 4-eyes-principle anymore, this will increase the risk of introducing
> hard bugs in a stable version again.
> I'm not saying we shouldn't do this.
> Especially as all our resources are much less these days and the
> 4-eyes-principle seems to make more work than we are willing to spend
> currently.
> I just want that you all are aware of this.

You are right, it increases the risk of releasing a version which
contains 
major bugs. But even with "pre" release, did it really happens once to
release a version with a major bug and that we have to fix in emergency
?
Maybe we would fix a big bug quicker without the merging process if
it happened.

> And there is another point to think about.
> If we do not create a stable branch, then anyone who might think about
> working on a new feature in trunk will probably think twice about it
> or don't think about it at all, as he doesn't want to be the one who
> is responsible for "yet another branch" that ppl want to prevent.
> This could hinder fresh jEdit development in the future.

I don't understand the point. In my case it was more often "I develop a
plugin, 
and instead of adding some code that could be common in jEdit's core,
I'll add it in my plugin so I don't have to wait the next year for a new
release
that will contains the new apis.

> Or even if it is about bugfixes, if I would take a try at a really
> complex bug, that is no show-stopper though, I might try to fix it in
> trunk, but I might want to NOT do this in the stable branch as it is
> too risky to introduce new other bugs.
> I did such fixes in the past which I wouldn't have done if the trunk
> would have been the stable branch at that time.

The stable branch can be an option in fact. If you are in such case, you
fix your complex bug that can introduce a risk in trunk.
Then if we need to release a new jEdit version and you think that the 
trunk is too risky, we can create a branch from the last tagged version
and fix bugs in it doing merge. But only if we estimate that the trunk
is not
stable enough.


> So if we are not interested in 2. anymore, there is also another
> option that would remove the need of Alan doing the merges into the
> stable branch.
> If a developer thinks what he did should make it into the stable
> branch (just showstoppers or really major bugs probably), then he can
> simply merge it himself over, right after commiting it into trunk or
> later if he likes to.
> If it is only about showstoppers or really major bugs, then the patch
> releases are probably only needed seldomly but if, then short after
> the merge was done and the result tested for the bug.
> 
> 
> To solve the "I felt bored when writing plugins that uses new api to
> have to wait the next year to release my plugins." problem, what
> speaks against releasing more often?

Exactly, it was not directly related with the merge process but with
the "planning".

> For example every half year a minor release if it only contains minor
> features or bugfixes and if bigger things are done in trunk, we can
> still decide to increase the release schedule again.

I don't see the need for a planning here, why do we need to state
that we will do 1 version per year, or two ? Why not releasing version
exactly when we feel that we want to do it, but again do it quicker.
If we want a stabilization branch for a version, then stabilize it for a 
shorter period, 

> > As for the nightly releases, they tend to be very stable. I usually just do an update on my local copy of the code and build and run that. I've been doing that for years and never had any significant problems.
> 
> I don't doubt they are stable. But you will not be able to convince
> the regular users to test those instead of a pre-release, not on a
> daily basis. Well, maybe 5-10% of them, but not more. Which is
> probably ok as long as only bugfixes are done and pre-releases are
> made if there is major new functionality to test.

But we can still take one of the, and call it 5.2.1 (or any version) and
say that it is our new release.

Matthieu

Well, actually we introduced the current scheme out of two reasons as
far as I remember.

1. to be able to do new development in trunk while the stable version
can be hardened for release and improved with bugfix versions
2. to improve the quality of jEdit by having a 4-eyes-principle for
changes that make it into the stable version to not introduce bad bugs
lightly in the stable version

If it is just about 1., I totally agree that we can just save the
stable branch and fix bugs in trunk as long as only stuff that would
be merged into the stable branch anyway is added and then release
5.3.1, 5.3.2 and so on from trunk.
But I think this would not help with "I felt bored when writing
plugins that uses new api to have to wait the next year to release my
plugins.".

The more important thing is, if we now decide not to follow the
4-eyes-principle anymore, this will increase the risk of introducing
hard bugs in a stable version again.
I'm not saying we shouldn't do this.
Especially as all our resources are much less these days and the
4-eyes-principle seems to make more work than we are willing to spend
currently.
I just want that you all are aware of this.

And there is another point to think about.
If we do not create a stable branch, then anyone who might think about
working on a new feature in trunk will probably think twice about it
or don't think about it at all, as he doesn't want to be the one who
is responsible for "yet another branch" that ppl want to prevent.
This could hinder fresh jEdit development in the future.

Or even if it is about bugfixes, if I would take a try at a really
complex bug, that is no show-stopper though, I might try to fix it in
trunk, but I might want to NOT do this in the stable branch as it is
too risky to introduce new other bugs.
I did such fixes in the past which I wouldn't have done if the trunk
would have been the stable branch at that time.


So if we are not interested in 2. anymore, there is also another
option that would remove the need of Alan doing the merges into the
stable branch.
If a developer thinks what he did should make it into the stable
branch (just showstoppers or really major bugs probably), then he can
simply merge it himself over, right after commiting it into trunk or
later if he likes to.
If it is only about showstoppers or really major bugs, then the patch
releases are probably only needed seldomly but if, then short after
the merge was done and the result tested for the bug.


To solve the "I felt bored when writing plugins that uses new api to
have to wait the next year to release my plugins." problem, what
speaks against releasing more often?
For example every half year a minor release if it only contains minor
features or bugfixes and if bigger things are done in trunk, we can
still decide to increase the release schedule again.



> As for the nightly releases, they tend to be very stable. I usually just do an update on my local copy of the code and build and run that. I've been doing that for years and never had any significant problems.

I don't doubt they are stable. But you will not be able to convince
the regular users to test those instead of a pre-release, not on a
daily basis. Well, maybe 5-10% of them, but not more. Which is
probably ok as long as only bugfixes are done and pre-releases are
made if there is major new functionality to test.

I don't wanna merge into stable anymore anyway.
I don't have time for that.

"I remember when I was more active on jEdit, I felt bored when writing
plugins that uses new api to have to wait the next year to release my
plugins."

+1!

As for the nightly releases, they tend to be very stable. I usually just do
an update on my local copy of the code and build and run that. I've been
doing that for years and never had any significant problems.

I agree with Matthieu, I think we're making this harder than it needs to
be. There are no really major changes going on anyway, so the risks are
quite low, I think.



On Mon, Jun 8, 2015 at 2:07 PM, Matthieu Casanova <cho...@gm...>
wrote:

> Vampire,
> you are maybe right, but I think the release process is too long, why
> keeping the idea of one release per year only ?
>
> Don't you think maintaining two branches of jEdit is too much work ?
>
> At this time we have something like that
>
> branch/5.2
> tag/5.2
> tag/5.2.1
> tag/5.2.2
> trunk (5.3)
>
> all bugfixes done in 5.3 should be merged in 5.2, it is a lot of work.
>
> Why not doing this after the next release
>
> tag/5.3
> trunk (5.3)
>
> Until a major feature is added or an api changed, trunk remains 5.3, and
> we release 5.3.1, 5.3.2 more often from that trunk.
> If we need to change the version of trunk, then it will be 5.4 or 6, but
> we don't create a branch for 5.3.
> A branch of 5.3 is necessary only if we wait too long before releasing
> the trunk again, so we can release a 5.4pre1 (or call it the way you
> want) and as soon as we fill it is stable enough release 5.4.
> This way we make the economy of doing a branch and merges, jEdit would
> look more active. And if we really need to fix a bug in 5.3 but 5.4 is
> not ready it is still possible to do a branch at this time.
>
> I remember when I was more active on jEdit, I felt bored when writing
> plugins that uses new api to have to wait the next year to release my
> plugins.
>
>
> --
>   Matthieu Casanova
>   cho...@gm...
>
> Le Lun 08 juin 2015, à 19:09, Vampire a écrit :
> > > Why ? Instead of testing pre-release people can test nightly build,
> don't you think ?
> >
> > Well, they *could*.
> > The point is, that they will not, or only very few.
> > I personally use never nightlies of any software, except there is bug
> > fixed that really bugs me, because I don't consider nightly builds as
> > stable as they are deemed to be broken regularly, that's just the
> > nature of nightlies.
> >
> > An official pre-release where the devs say "this is stable enough for
> > every-day use we believe, please test it to give us feedback" is
> > another kettle of fish.
> > You will get many more people to test a preliminary build if it is an
> > official pre-release than if it is a nightly build, even if you say
> > "hey, the nightlies are stable, please test them".
> > This is unfortunately just not how users work and think.
> >
> > So yes, I think if dev gets heavier again, I think pre-releases should
> > be made again to stabilize the release,
> > otherwise we would become one of those projects where you say "do not
> > install a .0 release, wait until the first few hotfixes are released,
> > before it is not stable".
> > I've used a couple of those projects and I wouldn't like to make jEdit
> > one of those.
> >
> >
> > > I've looked at the changes Makarius has made, and they are pretty
> minor. I think he's just being cautious since these are his first changes
> to jEdit core code.
> >
> > Ok, great then, I just had seen his comment I quoted. :-)
> >
> >
> > 2015-05-29 19:11 GMT+02:00 Dale Anson <da...@da...>:
> > > I've looked at the changes Makarius has made, and they are pretty
> minor. I
> > > think he's just being cautious since these are his first changes to
> jEdit
> > > core code.
> > >
> > > Dale
> > >
> > >
> > > On Fri, May 29, 2015 at 9:30 AM, Matthieu Casanova <
> cho...@gm...>
> > > wrote:
> > >>
> > >> Why ? Instead of testing pre-release people can test nightly build,
> > >> don't you think ?
> > >>
> > >> Le Ven 29 mai 2015, à 16:04, Björn Kautler a écrit :
> > >> > Well, just have seen "Since this is a change that affects
> appearance,
> > >> > it should be tested by other
> > >> > people as well, before the current release is shipped." from
> Makarius,
> > >> > so maybe we should NOT skip pre-phase?
> > >> >
> > >> > 2015-05-29 15:55 GMT+02:00 Björn Kautler <Bj...@ka...>:
> > >> > > Hey Alan,
> > >> > >
> > >> > > glad to see you back in charge. :-)
> > >> > >
> > >> > > Sure, if there is no big changes in 5.3 that should be tested by a
> > >> > > broader audience, but mostly bug-fixes or micro-features, we can
> > >> > > directly hop into 5.3.0, I agree.
> > >> > > After active development come back (let us be positive in mind
> :-) ),
> > >> > > we can start with a pre-release again for the version due then.
> :-)
> > >> > >
> > >> > > So a +1 from me too for 5.3.
> > >> > >
> > >> > > Cheers
> > >> > > Björn
> > >> > >
> > >> > >
> > >> > > 2015-05-21 8:50 GMT+02:00 ti...@ep... <ti...@ep...>:
> > >> > >> Sounds fine to me (thats 5 in case anyone is counting)
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> Sent from my LG Mobile
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> ------ Original message------
> > >> > >>
> > >> > >> From: Eric Berry
> > >> > >>
> > >> > >> Date: Thu, 21 May 2015 03:49
> > >> > >>
> > >> > >> To: Dale Anson;
> > >> > >>
> > >> > >> Cc: jEdit Dev List;
> > >> > >>
> > >> > >> Subject:Re: [ jEdit-devel ] new release plan: 5.3.0, 5.3.1, etc.
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> +1 from me too (4 in favor).
> > >> > >>
> > >> > >> On Wed, May 20, 2015 at 5:00 PM, Dale Anson <da...@da...>
> > >> > >> wrote:
> > >> > >>>
> > >> > >>> +1
> > >> > >>>
> > >> > >>> On Wed, May 20, 2015 at 4:19 PM, Alan Ezust <
> ala...@gm...>
> > >> > >>> wrote:
> > >> > >>>>
> > >> > >>>> Matthieu and I talked about how to do jEdit releases in the
> future.
> > >> > >>>> We
> > >> > >>>> both are tired of waiting for the ".0" to come out after the
> "pre".
> > >> > >>>>
> > >> > >>>> Since jEdit is not under really active development anymore,
> and we
> > >> > >>>> are
> > >> > >>>> just rolling in patches and bugfixes from the community, it
> might
> > >> > >>>> make more
> > >> > >>>> sense to just stop bothering with the stabilization phase, and
> > >> > >>>> release 5.3.0
> > >> > >>>> next, 5.3.1 after that, and 5.3.2, etc.
> > >> > >>>>
> > >> > >>>> So since Matthieu and I both agree, that is 2 in favor. Any
> > >> > >>>> against?
> > >> > >>>>
> > >> > >>>> I will continue accepting patches submitted in May and let's
> target
> > >> > >>>> to
> > >> > >>>> release 5.3.0 in early to mid June.
> > >> > >>>>
> > >> > >>>>
> > >> > >>>> --Alan
> > >> > >>>>
> > >> > >>>>
> > >> > >>>>
> > >> > >>>>
> > >> > >>>>
> > >> > >>>>
> ------------------------------------------------------------------------------
> > >> > >>>> One dashboard for servers and applications across
> > >> > >>>> Physical-Virtual-Cloud
> > >> > >>>> Widest out-of-the-box monitoring support with 50+ applications
> > >> > >>>> Performance metrics, stats and reports that give you Actionable
> > >> > >>>> Insights
> > >> > >>>> Deep dive visibility with transaction tracing using APM
> Insight.
> > >> > >>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > >> > >>>> --
> > >> > >>>> -----------------------------------------------
> > >> > >>>> jEdit Developers' List
> > >> > >>>> jEd...@li...
> > >> > >>>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> > >> > >>>>
> > >> > >>>
> > >> > >>>
> > >> > >>>
> > >> > >>>
> > >> > >>>
> ------------------------------------------------------------------------------
> > >> > >>> One dashboard for servers and applications across
> > >> > >>> Physical-Virtual-Cloud
> > >> > >>> Widest out-of-the-box monitoring support with 50+ applications
> > >> > >>> Performance metrics, stats and reports that give you Actionable
> > >> > >>> Insights
> > >> > >>> Deep dive visibility with transaction tracing using APM Insight.
> > >> > >>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > >> > >>> --
> > >> > >>> -----------------------------------------------
> > >> > >>> jEdit Developers' List
> > >> > >>> jEd...@li...
> > >> > >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> > >> > >>>
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> --
> > >> > >> Learn from the past. Live in the present. Work towards the
> future.
> > >> > >> Blog: http://eric-berry.blogspot.com
> > >> > >> jEdit <http://www.jedit.org> - Programmer's Text Editor
> > >> > >>
> > >> > >>
> > >> > >>
> ------------------------------------------------------------------------------
> > >> > >> One dashboard for servers and applications across
> > >> > >> Physical-Virtual-Cloud
> > >> > >> Widest out-of-the-box monitoring support with 50+ applications
> > >> > >> Performance metrics, stats and reports that give you Actionable
> > >> > >> Insights
> > >> > >> Deep dive visibility with transaction tracing using APM Insight.
> > >> > >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > >> > >> --
> > >> > >> -----------------------------------------------
> > >> > >> jEdit Developers' List
> > >> > >> jEd...@li...
> > >> > >> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> > >> > >>
> > >> >
> > >> >
> > >> >
> ------------------------------------------------------------------------------
> > >> > --
> > >> > -----------------------------------------------
> > >> > jEdit Developers' List
> > >> > jEd...@li...
> > >> > https://lists.sourceforge.net/lists/listinfo/jedit-devel
> > >>
> > >>
> > >> --
> > >>   Matthieu Casanova
> > >>   cho...@gm...
> > >>
> > >>
> > >>
> ------------------------------------------------------------------------------
> > >> --
> > >> -----------------------------------------------
> > >> jEdit Developers' List
> > >> jEd...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > >
> > > --
> > > -----------------------------------------------
> > > jEdit Developers' List
> > > jEd...@li...
> > > https://lists.sourceforge.net/lists/listinfo/jedit-devel
> > >
>
>

Vampire,
you are maybe right, but I think the release process is too long, why
keeping the idea of one release per year only ?

Don't you think maintaining two branches of jEdit is too much work ?

At this time we have something like that

branch/5.2
tag/5.2
tag/5.2.1
tag/5.2.2
trunk (5.3)

all bugfixes done in 5.3 should be merged in 5.2, it is a lot of work.

Why not doing this after the next release

tag/5.3
trunk (5.3)

Until a major feature is added or an api changed, trunk remains 5.3, and
we release 5.3.1, 5.3.2 more often from that trunk.
If we need to change the version of trunk, then it will be 5.4 or 6, but
we don't create a branch for 5.3.
A branch of 5.3 is necessary only if we wait too long before releasing
the trunk again, so we can release a 5.4pre1 (or call it the way you
want) and as soon as we fill it is stable enough release 5.4.
This way we make the economy of doing a branch and merges, jEdit would
look more active. And if we really need to fix a bug in 5.3 but 5.4 is
not ready it is still possible to do a branch at this time.

I remember when I was more active on jEdit, I felt bored when writing
plugins that uses new api to have to wait the next year to release my
plugins.


-- 
  Matthieu Casanova
  cho...@gm...

Le Lun 08 juin 2015, à 19:09, Vampire a écrit :
> > Why ? Instead of testing pre-release people can test nightly build, don't you think ?
> 
> Well, they *could*.
> The point is, that they will not, or only very few.
> I personally use never nightlies of any software, except there is bug
> fixed that really bugs me, because I don't consider nightly builds as
> stable as they are deemed to be broken regularly, that's just the
> nature of nightlies.
> 
> An official pre-release where the devs say "this is stable enough for
> every-day use we believe, please test it to give us feedback" is
> another kettle of fish.
> You will get many more people to test a preliminary build if it is an
> official pre-release than if it is a nightly build, even if you say
> "hey, the nightlies are stable, please test them".
> This is unfortunately just not how users work and think.
> 
> So yes, I think if dev gets heavier again, I think pre-releases should
> be made again to stabilize the release,
> otherwise we would become one of those projects where you say "do not
> install a .0 release, wait until the first few hotfixes are released,
> before it is not stable".
> I've used a couple of those projects and I wouldn't like to make jEdit
> one of those.
> 
> 
> > I've looked at the changes Makarius has made, and they are pretty minor. I think he's just being cautious since these are his first changes to jEdit core code.
> 
> Ok, great then, I just had seen his comment I quoted. :-)
> 
> 
> 2015-05-29 19:11 GMT+02:00 Dale Anson <da...@da...>:
> > I've looked at the changes Makarius has made, and they are pretty minor. I
> > think he's just being cautious since these are his first changes to jEdit
> > core code.
> >
> > Dale
> >
> >
> > On Fri, May 29, 2015 at 9:30 AM, Matthieu Casanova <cho...@gm...>
> > wrote:
> >>
> >> Why ? Instead of testing pre-release people can test nightly build,
> >> don't you think ?
> >>
> >> Le Ven 29 mai 2015, à 16:04, Björn Kautler a écrit :
> >> > Well, just have seen "Since this is a change that affects appearance,
> >> > it should be tested by other
> >> > people as well, before the current release is shipped." from Makarius,
> >> > so maybe we should NOT skip pre-phase?
> >> >
> >> > 2015-05-29 15:55 GMT+02:00 Björn Kautler <Bj...@ka...>:
> >> > > Hey Alan,
> >> > >
> >> > > glad to see you back in charge. :-)
> >> > >
> >> > > Sure, if there is no big changes in 5.3 that should be tested by a
> >> > > broader audience, but mostly bug-fixes or micro-features, we can
> >> > > directly hop into 5.3.0, I agree.
> >> > > After active development come back (let us be positive in mind :-) ),
> >> > > we can start with a pre-release again for the version due then. :-)
> >> > >
> >> > > So a +1 from me too for 5.3.
> >> > >
> >> > > Cheers
> >> > > Björn
> >> > >
> >> > >
> >> > > 2015-05-21 8:50 GMT+02:00 ti...@ep... <ti...@ep...>:
> >> > >> Sounds fine to me (thats 5 in case anyone is counting)
> >> > >>
> >> > >>
> >> > >>
> >> > >> Sent from my LG Mobile
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >> ------ Original message------
> >> > >>
> >> > >> From: Eric Berry
> >> > >>
> >> > >> Date: Thu, 21 May 2015 03:49
> >> > >>
> >> > >> To: Dale Anson;
> >> > >>
> >> > >> Cc: jEdit Dev List;
> >> > >>
> >> > >> Subject:Re: [ jEdit-devel ] new release plan: 5.3.0, 5.3.1, etc.
> >> > >>
> >> > >>
> >> > >>
> >> > >> +1 from me too (4 in favor).
> >> > >>
> >> > >> On Wed, May 20, 2015 at 5:00 PM, Dale Anson <da...@da...>
> >> > >> wrote:
> >> > >>>
> >> > >>> +1
> >> > >>>
> >> > >>> On Wed, May 20, 2015 at 4:19 PM, Alan Ezust <ala...@gm...>
> >> > >>> wrote:
> >> > >>>>
> >> > >>>> Matthieu and I talked about how to do jEdit releases in the future.
> >> > >>>> We
> >> > >>>> both are tired of waiting for the ".0" to come out after the "pre".
> >> > >>>>
> >> > >>>> Since jEdit is not under really active development anymore, and we
> >> > >>>> are
> >> > >>>> just rolling in patches and bugfixes from the community, it might
> >> > >>>> make more
> >> > >>>> sense to just stop bothering with the stabilization phase, and
> >> > >>>> release 5.3.0
> >> > >>>> next, 5.3.1 after that, and 5.3.2, etc.
> >> > >>>>
> >> > >>>> So since Matthieu and I both agree, that is 2 in favor. Any
> >> > >>>> against?
> >> > >>>>
> >> > >>>> I will continue accepting patches submitted in May and let's target
> >> > >>>> to
> >> > >>>> release 5.3.0 in early to mid June.
> >> > >>>>
> >> > >>>>
> >> > >>>> --Alan
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>> ------------------------------------------------------------------------------
> >> > >>>> One dashboard for servers and applications across
> >> > >>>> Physical-Virtual-Cloud
> >> > >>>> Widest out-of-the-box monitoring support with 50+ applications
> >> > >>>> Performance metrics, stats and reports that give you Actionable
> >> > >>>> Insights
> >> > >>>> Deep dive visibility with transaction tracing using APM Insight.
> >> > >>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> >> > >>>> --
> >> > >>>> -----------------------------------------------
> >> > >>>> jEdit Developers' List
> >> > >>>> jEd...@li...
> >> > >>>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >> > >>>>
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> ------------------------------------------------------------------------------
> >> > >>> One dashboard for servers and applications across
> >> > >>> Physical-Virtual-Cloud
> >> > >>> Widest out-of-the-box monitoring support with 50+ applications
> >> > >>> Performance metrics, stats and reports that give you Actionable
> >> > >>> Insights
> >> > >>> Deep dive visibility with transaction tracing using APM Insight.
> >> > >>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> >> > >>> --
> >> > >>> -----------------------------------------------
> >> > >>> jEdit Developers' List
> >> > >>> jEd...@li...
> >> > >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >> > >>>
> >> > >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Learn from the past. Live in the present. Work towards the future.
> >> > >> Blog: http://eric-berry.blogspot.com
> >> > >> jEdit <http://www.jedit.org> - Programmer's Text Editor
> >> > >>
> >> > >>
> >> > >> ------------------------------------------------------------------------------
> >> > >> One dashboard for servers and applications across
> >> > >> Physical-Virtual-Cloud
> >> > >> Widest out-of-the-box monitoring support with 50+ applications
> >> > >> Performance metrics, stats and reports that give you Actionable
> >> > >> Insights
> >> > >> Deep dive visibility with transaction tracing using APM Insight.
> >> > >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> >> > >> --
> >> > >> -----------------------------------------------
> >> > >> jEdit Developers' List
> >> > >> jEd...@li...
> >> > >> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >> > >>
> >> >
> >> >
> >> > ------------------------------------------------------------------------------
> >> > --
> >> > -----------------------------------------------
> >> > jEdit Developers' List
> >> > jEd...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >>
> >>
> >> --
> >>   Matthieu Casanova
> >>   cho...@gm...
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> --
> >> -----------------------------------------------
> >> jEdit Developers' List
> >> jEd...@li...
> >> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >
> >
> >
> > ------------------------------------------------------------------------------
> >
> > --
> > -----------------------------------------------
> > jEdit Developers' List
> > jEd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >

> Why ? Instead of testing pre-release people can test nightly build, don't you think ?

Well, they *could*.
The point is, that they will not, or only very few.
I personally use never nightlies of any software, except there is bug
fixed that really bugs me, because I don't consider nightly builds as
stable as they are deemed to be broken regularly, that's just the
nature of nightlies.

An official pre-release where the devs say "this is stable enough for
every-day use we believe, please test it to give us feedback" is
another kettle of fish.
You will get many more people to test a preliminary build if it is an
official pre-release than if it is a nightly build, even if you say
"hey, the nightlies are stable, please test them".
This is unfortunately just not how users work and think.

So yes, I think if dev gets heavier again, I think pre-releases should
be made again to stabilize the release,
otherwise we would become one of those projects where you say "do not
install a .0 release, wait until the first few hotfixes are released,
before it is not stable".
I've used a couple of those projects and I wouldn't like to make jEdit
one of those.


> I've looked at the changes Makarius has made, and they are pretty minor. I think he's just being cautious since these are his first changes to jEdit core code.

Ok, great then, I just had seen his comment I quoted. :-)


2015-05-29 19:11 GMT+02:00 Dale Anson <da...@da...>:
> I've looked at the changes Makarius has made, and they are pretty minor. I
> think he's just being cautious since these are his first changes to jEdit
> core code.
>
> Dale
>
>
> On Fri, May 29, 2015 at 9:30 AM, Matthieu Casanova <cho...@gm...>
> wrote:
>>
>> Why ? Instead of testing pre-release people can test nightly build,
>> don't you think ?
>>
>> Le Ven 29 mai 2015, à 16:04, Björn Kautler a écrit :
>> > Well, just have seen "Since this is a change that affects appearance,
>> > it should be tested by other
>> > people as well, before the current release is shipped." from Makarius,
>> > so maybe we should NOT skip pre-phase?
>> >
>> > 2015-05-29 15:55 GMT+02:00 Björn Kautler <Bj...@ka...>:
>> > > Hey Alan,
>> > >
>> > > glad to see you back in charge. :-)
>> > >
>> > > Sure, if there is no big changes in 5.3 that should be tested by a
>> > > broader audience, but mostly bug-fixes or micro-features, we can
>> > > directly hop into 5.3.0, I agree.
>> > > After active development come back (let us be positive in mind :-) ),
>> > > we can start with a pre-release again for the version due then. :-)
>> > >
>> > > So a +1 from me too for 5.3.
>> > >
>> > > Cheers
>> > > Björn
>> > >
>> > >
>> > > 2015-05-21 8:50 GMT+02:00 ti...@ep... <ti...@ep...>:
>> > >> Sounds fine to me (thats 5 in case anyone is counting)
>> > >>
>> > >>
>> > >>
>> > >> Sent from my LG Mobile
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> ------ Original message------
>> > >>
>> > >> From: Eric Berry
>> > >>
>> > >> Date: Thu, 21 May 2015 03:49
>> > >>
>> > >> To: Dale Anson;
>> > >>
>> > >> Cc: jEdit Dev List;
>> > >>
>> > >> Subject:Re: [ jEdit-devel ] new release plan: 5.3.0, 5.3.1, etc.
>> > >>
>> > >>
>> > >>
>> > >> +1 from me too (4 in favor).
>> > >>
>> > >> On Wed, May 20, 2015 at 5:00 PM, Dale Anson <da...@da...>
>> > >> wrote:
>> > >>>
>> > >>> +1
>> > >>>
>> > >>> On Wed, May 20, 2015 at 4:19 PM, Alan Ezust <ala...@gm...>
>> > >>> wrote:
>> > >>>>
>> > >>>> Matthieu and I talked about how to do jEdit releases in the future.
>> > >>>> We
>> > >>>> both are tired of waiting for the ".0" to come out after the "pre".
>> > >>>>
>> > >>>> Since jEdit is not under really active development anymore, and we
>> > >>>> are
>> > >>>> just rolling in patches and bugfixes from the community, it might
>> > >>>> make more
>> > >>>> sense to just stop bothering with the stabilization phase, and
>> > >>>> release 5.3.0
>> > >>>> next, 5.3.1 after that, and 5.3.2, etc.
>> > >>>>
>> > >>>> So since Matthieu and I both agree, that is 2 in favor. Any
>> > >>>> against?
>> > >>>>
>> > >>>> I will continue accepting patches submitted in May and let's target
>> > >>>> to
>> > >>>> release 5.3.0 in early to mid June.
>> > >>>>
>> > >>>>
>> > >>>> --Alan
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> ------------------------------------------------------------------------------
>> > >>>> One dashboard for servers and applications across
>> > >>>> Physical-Virtual-Cloud
>> > >>>> Widest out-of-the-box monitoring support with 50+ applications
>> > >>>> Performance metrics, stats and reports that give you Actionable
>> > >>>> Insights
>> > >>>> Deep dive visibility with transaction tracing using APM Insight.
>> > >>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> > >>>> --
>> > >>>> -----------------------------------------------
>> > >>>> jEdit Developers' List
>> > >>>> jEd...@li...
>> > >>>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>> > >>>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> ------------------------------------------------------------------------------
>> > >>> One dashboard for servers and applications across
>> > >>> Physical-Virtual-Cloud
>> > >>> Widest out-of-the-box monitoring support with 50+ applications
>> > >>> Performance metrics, stats and reports that give you Actionable
>> > >>> Insights
>> > >>> Deep dive visibility with transaction tracing using APM Insight.
>> > >>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> > >>> --
>> > >>> -----------------------------------------------
>> > >>> jEdit Developers' List
>> > >>> jEd...@li...
>> > >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>> > >>>
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Learn from the past. Live in the present. Work towards the future.
>> > >> Blog: http://eric-berry.blogspot.com
>> > >> jEdit <http://www.jedit.org> - Programmer's Text Editor
>> > >>
>> > >>
>> > >> ------------------------------------------------------------------------------
>> > >> One dashboard for servers and applications across
>> > >> Physical-Virtual-Cloud
>> > >> Widest out-of-the-box monitoring support with 50+ applications
>> > >> Performance metrics, stats and reports that give you Actionable
>> > >> Insights
>> > >> Deep dive visibility with transaction tracing using APM Insight.
>> > >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> > >> --
>> > >> -----------------------------------------------
>> > >> jEdit Developers' List
>> > >> jEd...@li...
>> > >> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>> > >>
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > --
>> > -----------------------------------------------
>> > jEdit Developers' List
>> > jEd...@li...
>> > https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
>>
>> --
>>   Matthieu Casanova
>>   cho...@gm...
>>
>>
>> ------------------------------------------------------------------------------
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>
>
> ------------------------------------------------------------------------------
>
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>