Hi,

Just got an article about new language features from RO's Oxygene language. I think some of them might be good to be (considered and) implemented in FPC v.3.

http://blogs.remobjects.com/blogs/mh/2015/01/28/p7049

What do you think? :)

Regards,

"Bee" wrote

Hi, Just got an article about new language features from RO's Oxygene

language. I think some of them might be good to be (considered and) implemented in FPC v.3.

Some features are interesting and are on my own ToDo list (for example tuples). There will however be no roadmap for these features and more importantly they won't be part of 3.0, because that version is currently prepared for release and thus has a feature freeze.

Regards,
Sven

It would be nice if FPC adopt RC versions. So anyone could do tests just installing it via setup, instead of using GIT / SVN. And Lazarus RCs could be release using this RCs FPCs (e.g: Lazarus-1.4-RC1 has FPC-3.0.0-RC1).

- RCs - every three or six months;
- stable - a year.

And Lazarus RCs could be release using this RCs FPCs (e.g: Lazarus-1.4-RC1

has FPC-3.0.0-RC1).

I think it's a bad idea to release an RC of Lazarus with RC of FPC, remembering both are separate projects where Lazarus depends on FPC. Independent release where Lazarus depends on latest stable FPC is a good decision already.

Are you confusing Minor versions with Release Candidates?

Mattias

We /are/ doing RCs just like we've done in the past. Before 3.0.0 will be released there will at least be a 3.0.0RC1 and maybe also a 3.0.0RC2. But it takes time to prepare these and thus RCs are only prepared when a new release is planned. Everything else would be - simply spoken - a waste of our time that is better spent improving the compiler, the RTL and whatever else we have.

Regards,
Sven

I believe that would be nice a online poll about this. =/

Lazarus community is very large, with several Lazarus and Delphi programmers, then it would be interesting to facilitate they testing of new FPC features, even for a programmer without GIT / SVN knowledge: 'just download a setup/DEB/RPM and enjoy it!'.

Today, if I need to test new features of the compiler, or I acquire knowledge about GIT / SVN / compile from sources, or I use third party solutions (command lines tool, shell scripts, articles, IDEs etc). =(

The problem is that FPC take a lot of time to release new versions. If there was a version (RCs) every six months it would help a lot.

Today I'm 32 years old, and probably I'll see the FPC 3.0 be released when I'm 33 years old. FPC 4.0 -> 40 years old. FPC 5.0 -> I will be already retired. =D

Just suggestions. I follow other programmer tools, and they don't take much time to release new versions, and some of them have fewer programmers that FPC community. =/

silvioprog wrote

The problem is that FPC take a lot of time to release new versions. If there was a version (RCs) every six months it would help a lot.

The point is: it takes a lot of time to prepare and test the releases and also to coordinate the efforts.

Which of them are multiplatform (~25) and do binary releases?

If the snapshots would still be generated you could download Lazarus 1.5 with FPC 3.1.1 without problems. But apparently that stopped, otherwise they would be here: ftp://freepascal.dfmk.hu/pub/lazarus/snapshots/

Regards,
Sven

You shouldn't bother with version numbers too much. The next version could have as easily been 2.8 and the one after it 2.10. It's the features that count... And our normal rythm is a major release around every two years (currently a bit longer with 3.0, but nobody's perfect...)

Just suggestions. I follow other programmer tools, and they don't take much time to release new versions, and some of them have fewer programmers that FPC community. =/

Regards,
Sven

Yes. But I have a question: who does the tests? Only the FPC core and advanced programmers?! =/

My suggestion is to allow any programmer to test the new compiler features. If more people can test it, more chances to release a stable version.

Most of them (Nginx; Chrome; VirtualBox; SMPlayer; WGet; SmartGIT ...). I know that release a new version of a compiler is more complex than a common tool, but it take a long time to release a version of any tool, discourages who is following it.

My suggestion is just: to make easier to test, for any programmer. E.g:

- fpc-3.0.0-beta1/beta2 +/-jan/feb
- fpc-3.0.0-RC1/RC2 +/-may/jun
- fpc-3.0.0-RC3/fpc-3.0.0-stable +/-dec.

Yes, it is hard to do, but IMHO it is necessary.

Yes. Snapshot is very good, but unfortunately it seems stopped. =(

The snapshots could solve the necessity of RCs versions.

Yes, I know. I don't bother with numbers, I bother with the time between releases, that is very long.

The 'revival' of snapshot would be nice to solve the new releases needs.

It is not only doing a few clicks but testing includes also fixing obviously. It can be done by everybody. Good start are the installer bug reports in the bug tracker.

My suggestion is to allow any programmer to test the new compiler features.

It is not about feature testing but installation testing on different OSes, regression testing on different OSes etc. and fixing everything (!).

I said ~25 platforms :) Not only a handfull plaforms released by big companies.

Throwing out broken release every two months is not helpfull. Two months is normally the time span which is needed from the start of the preparation of a release to the final release.

In our previous episode, silvioprog said:

I don't think this needs to be done formally. Any users can package snapshots cq pseudo releases and mark them as test, and release them for feedback. Then process the feedback, triage it, and communicate that back upstream.

That's how the really big projects (like distros) work too. Similarly with the various branches of the Linux kernel, where there are often third party builders that track a certain target.

So the question should be, when do you think you can release your first pseudo stable snapshot? Throwing it all back to core is useless, since that increasing tasks will only slow development more.

Yes. Snapshot is very good, but unfortunately it seems stopped. =(

+1

The snapshots could solve the necessity of RCs versions.

+1

-Laco.

What do you think? :)

Multiple times he says stuff like "... Currently on .NET only ... "

So seems that Oxygene now (finally) is available for native Archs (I did not check which ones).

Sadly, the (IMHO) most interesting extension "parallel loop" is "Currently on .NET only" :(.

-Michael

not check which ones).

Oxygene is available for .Net, Android (JVM based) and iOS (native).

Sadly, the (IMHO) most interesting extension "parallel loop" is

"Currently on .NET only" :(.

Oxygene relies heavily on the features provided by the underlying runtime (CLR, JVM, ObjC) and thus they can't provide each language feature everywhere.

Regards,
Sven

Sven Barth wrote

Oxygene relies heavily on the features provided by the underlying runtime (CLR, JVM, ObjC) and thus they can't provide each language feature everywhere.

... While the beauty of fpc is the true cross-platform design :-)

-Michael

Hi Marco,

Which sometimes takes so long, that the downstream tester bypasses the distro maintainers and submits patches directly upstream... ... only to find out that his patches are not going to be present in /this/ incarnation of the distro release and he'll be lucky if they actually hit the next one.

That's how the really big projects (like distros) work too. Similarly with the various branches of the Linux kernel, where there are often third party builders that track a certain target.

Linux approach changed around 2.6.12 somewhere (or later) with/after the upcome of git... now they have 6-9 rc releases, merging new features AND bugfixes, one per week or 1.5 average, then branch the head off and the stable branch is strongly advised to be sent bugfixes /only/.

This alone has reduced the gap between what distros used to package, even if it's wheezy-backports I have to add to my repo list to get a 3.16 kernel... while the head is 3.19 looming on 4.0; but that is only 4 major* releases behind - when in early days they went on forever maintaining up to 2.4.89, because there was demand... and still some people/distros stayed on 2.4.[pick an earlier number] and grumbled... about the threshold of switching to 2.6.x ... or even to 2.4.x+1 sometimes.

(Truth be said, I /do/ see resemblance of LK to FPC approach, only FPC has a slower pace and uses different numbering scheme, (which can be (mildly) confusing when one switches contexts often;) also you call it feature-freeze, they call it stable branch... but it's the same idea in its essence)

(* yeah, yeah, they call it 'minor', so what. any release I don't have yet, is a major one to me)

So the question should be, when do you think you can release your first pseudo stable snapshot? Throwing it all back to core is useless, since that increasing tasks will only slow development more.

I for one think, that just encouraging /anybody/ to release pseudo-stable snapshots, is not going to help, rather end up with some of them being forks, fragmenting the ecosystem... (remember the times of linux 2.4.x-ac or -mm versions?)

You might end up with some people that are less patient instantiating their own git repos, and adopting faster pace, and the main repos becoming outdated... because their downstream patches won't apply to upstream without considerable amount of work.

I'm actually with Silvio on this : do keep calm and carry on with your numbers scheme, since it suits your needs;
only maybe shorten the time between major stable releases ?

(maybe by altering the criteria, of how much of a change is considered fit for a next major release,

  /considerably/ down;

even if it means, if tracking the features of Delphi compiler is any factor, that for 1 Delphi release, FPC releases 5 or 6 major releases before it catches up)

So that you get the downstream people tracking /behind/ you, not reverse : smaller changes made more often, are proven to be more stable, and are less of a burden on testers, and less trouble porting programs from one version to next version, as Linux example actually does show.

Just My 2 zl / 20p ;) worth of synthesis/comparisions from reading LKML and FPC-general list ;)

(and I'm just a user who likes using stable releases ;) but Lazarus in my wheezy from main repo is 0.9.30.4 ... how old is that...? )

Lukasz

In our previous episode, Lukasz Sokol said:

True. This happens with FPC too, if some feature is postponed to the next major version that can be a long time. But that some projects take even more time doesn't mean the principle is flawed.

And they have a staging branch before that. I meant with the example that the stable, head and staging groups are managed by different people and teams.

(Truth be said, I /do/ see resemblance of LK to FPC approach, only FPC has a slower pace and uses different numbering scheme, (which can be (mildly) confusing when one switches contexts often;) also you call it feature-freeze, they call it stable branch... but it's the same idea in its essence)

Linux is big business. FPC not. The core point of the analogy is that not every detail of all work within a project needs to go through /one/ central point. (like the FPC core team in our case or Ueberpenguin Linus in the Linux kernel)

They served a purpose, even if the purpose is no longer needed later. Moreover it has no point to compare with an ideal scenario (new version of fpc every quarter major branch per year or so) that is never going to happen.

What FPC needs is longterm committed people on both development and maintenance topics.

You might end up with some people that are less patient instantiating their own git repos, and adopting faster pace, and the main repos becoming outdated... because their downstream patches won't apply to upstream without considerable amount of work.

That simply can't be stopped. It is of course annoying since usually the support burden for such projects still falls on the original project (even if only 2nd line).

But anyone can suddenly imagine he can do a better job and start an independent branch, I don't think it is wise to let that fact influence how to setup the process too much.

I'm actually with Silvio on this

Silvio sets goals but doesn't provide the resources to do so. That is the crucial flaw in such rants.

(maybe by altering the criteria, of how much of a change is considered fit for a next major release, /considerably/ down; even if it means, if tracking the features of Delphi compiler is any factor, that for 1 Delphi release, FPC releases 5 or 6 major releases before it catches up)

That is another fundamental flaw, trying to plan something in a project that survives on voluntarily work of volunteers. There is nothing that CAN be steered top down in projects like this.

Marco van de Voort wrote

In our previous episode, Lukasz Sokol said:

[...]

That can be stopped, if the downstream projects like this, can be confident of their patches be present in next (major) release...

But anyone can suddenly imagine he can do a better job and start an independent branch, I don't think it is wise to let that fact influence how to setup the process too much.

Yeah only by setting an example maybe.

> I'm actually with Silvio on this Silvio sets goals but doesn't provide the resources to do so. That is the crucial flaw in such rants.

Please don't get us wrong, no one says this has to happen now, immediately or OVERNIGHT, it's more like if ... could some speedup be considered ...? Pretty please ? That's from me, ordinary user who lives on stable...

No one asks anyone to overstrain themselves really, and for what effect.

Only saying, that Linux's approach of the (major) releases happening at lightning speed, compared to what they were doing before, seems to also have effect of more exposure to whoever wants to participate (and other projects seem to be adopting that approach too), more patches and more interested eyeballs. (though probably need for thicker skin sometimes as well)

Well I can understand this... I'm not top-down, I'm the very end of the callchain :)

Lukasz

Unlikely, we even cannot keep pace with the bug reports.

The linux approach is to dump a source blob onto the user. I would happily change to this model, unfortunatly we have no distributors like linux who do the boring work for us and package fpc for ~25 platforms.

Florian Klämpfl wrote

Am 18.02.2015 um 14:03 schrieb Lukasz Sokol:

[...]

Unlikely, we even cannot keep pace with the bug reports.

I understand.

[...]

The linux approach is to dump a source blob onto the user.

And we FPC /users/ are 'suggested' to download&compile from SVN (even if it's just -fixes) if whatever our upstream packager provides is insufficient for whatever reason...

I would happily change to this model, unfortunatly we have no distributors like linux who do the boring work for us and package fpc for ~25 platforms.

OK, so I can see from here, what Marco said, about pseudo releases anyone can do, holds value to the above. That I can understand too. Only hope whoever volunteers to it, will be able to communicate / convey to upstream and not carried away with their own little world...

Lukasz

it's just -fixes)

if whatever our upstream packager provides is insufficient for whatever

reason...

You know that Florian was talking about releases? For the Linux kernel releases are just source blobs while for us releases are mostly binary ones. That's a big difference.
The Linux equivalent of us suggesting to download and compile from SVN would be to follow e.g. linux-next.git, do a pull every now and then and recompile and install the kernel.

Regards,
Sven

Yes.
You are right.
Did I say somewhere, that switching contexts between reading here and reading LKML is hard ;)

OK.

Regards, Sven

Lukasz