Is it possible to backport the resolution of 0007281 from head to fixes branch?
Best Regards, helmut
Mailing lists / fpc-devel / 2006-11
Bug 0007281 / MemLeak with interfaces
8 messages · 6 people · –
- Jonas Maebe 2
- Martin Schreiber 2
- Daniël Mantione 1
- Florian Klaempfl 1
- Helmut Hartl 1
- Peter Vreman 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Is it possible to backport the resolution of 0007281 from head to fixes branch?
It is not usefull to do. There won't be a new release anymore from the fixes branch.
Peter Vreman wrote 7 lines
> Is it possible to backport the resolution of 0007281 from head to fixes
> branch?
It is not usefull to do. There won't be a new release anymore from the
fixes branch.
But what should we do if we can't use trunk because it is not stable and we can't use 2.0.4 because it is buggy?
Martin
Op Wed, 8 Nov 2006, schreef Martin Schreiber:
Show quoted text 10 lines
On Tuesday 07 November 2006 17.46, Peter Vreman wrote:
> > Is it possible to backport the resolution of 0007281 from head to fixes
> > branch?
>
> It is not usefull to do. There won't be a new release anymore from the
> fixes branch.
>
>
But what should we do if we can't use trunk because it is not stable and we
can't use 2.0.4 because it is buggy?
If you need a certain bugfix, ask if it can be merged to 2.0.5, you can use a snapshot next day then. If things really get unworkable we could consider a release, but we prefer to do 2.2.0.
Daniël
But what should we do if we can't use trunk because it is not stable and we can't use…
Martin Schreiber wroteBut what should we do if we can't use trunk because it is not stable and we can't use 2.0.4 because it is buggy?
There will *always* be bugs in the latest release which cause it not to work for some people. If we'd release a 2.0.6, that situation would not change and some of those people would also think that their bug is so important it requires a new release.
Jonas
Jonas Maebe wrote 10 lines
On 8 nov 2006, at 06:52, Martin Schreiber wrote:
> But what should we do if we can't use trunk because it is not
> stable and we
> can't use 2.0.4 because it is buggy?
There will *always* be bugs in the latest release which cause it not
to work for some people. If we'd release a 2.0.6, that situation
would not change and some of those people would also think that their
bug is so important it requires a new release.
I don't think we need an 2.0.6 release but a continuously updated fixes_2_0 branch.
Martin
Martin Schreiber wrote 8 lines
> There will *always* be bugs in the latest release which cause it not
> to work for some people. If we'd release a 2.0.6, that situation
> would not change and some of those people would also think that their
> bug is so important it requires a new release.
I don't think we need an 2.0.6 release but a continuously updated
fixes_2_0
branch.
a) this has become more or less impossible now, because last week the internal structure and name of several often-used types changed in the main branch (which means you're going to get conflicts in every merge now)
b) before that, it would have taken useful time away from main development. I think such updating could in fact be perfectly done by someone else than the core developers. In general you don't need intricate knowledge of the compiler or other things. Before committing, just check whether everything still compiles after merging and whether there aren't any regressions in the test suite.
Jonas
Show quoted text 5 lines
I think such updating could in fact be perfectly done by
someone else than the core developers. In general you don't need
intricate knowledge of the compiler or other things. Before committing,
just check whether everything still compiles after merging and whether
there aren't any regressions in the test suite.
If anybody is willing to do so, he'll get svn write access so feel free to volounteer ;)