Possible break of compatibility warning ?

[Fred vS]

Hello.

Does it exist something that warn about a possible break of compatibility on a commit done in trunk?

There is https://wiki.freepascal.org/User_Changes_Trunk but I would like something more git-commit-focused.
For example a grid that add a line when a commit could affect compatibility, with the git-commit number and some explanation?.

Thanks.

[Thaddy]

Trunk is a moving target and therefor it would be very hard to maintain such things. Some features can be withdrawn etc... And you can already find out the commit using git.

[Fred vS]

And you can already find out the commit using git.

Hum, how to filter the commits with potentially break-compatibility using git, what key-word to use?

For example, for a "Merge request" there is a template with some questions, like "What is the current bug behavior?", ... etc.
Maybe this question could be added: "Could the patch generate break-compatibility? (yes/no)" and so a search with that filter could be done.

The same for commits, add a keyword when potentially break-compatibility to make the search easier.

[Thaddy]

https://git-scm.com/docs/user-manual.html

[Fred vS]

https://git-scm.com/docs/user-manual.html

 

[PascalDragon]

Does it exist something that warn about a possible break of compatibility on a commit done in trunk?

There is https://wiki.freepascal.org/User_Changes_Trunk but I would like something more git-commit-focused.
For example a grid that add a line when a commit could affect compatibility, with the git-commit number and some explanation?.

No. The only source for this is the referenced wiki article and there is no interest in changing this.

[Fred vS]

Does it exist something that warn about a possible break of compatibility on a commit done in trunk?

There is https://wiki.freepascal.org/User_Changes_Trunk but I would like something more git-commit-focused.
For example a grid that add a line when a commit could affect compatibility, with the git-commit number and some explanation?.

... there is no interest in changing this.

Huh, maybe for fpc core devs but for common users that maintain lib-apps code using fpc, there is interest.

But ok, thanks for the info and sorry for the noise.

Fre;D

[marcov]

(using commit messages as publishing method doesn't make sense anyway, since not all (detail) consequences are always known on the moment of commit. E.g. if Lazarus can work around it, or if it will be a compatibility problem till the next major version.  )

[Fred vS]

(using commit messages as publishing method doesn't make sense anyway, since not all (detail) consequences are always known on the moment of commit.  )

Yes, of course, it is why "possible break" could be added if a committer knows that the commit could break compatibility.
But, ok, I forget it.

[TRon]

Yes, of course, it is why "possible break" could be added if a committer knows that the commit could break compatibility.

That is exactly the problem.

Not every developer knows upfront if his/her changes will break something (for various reasons).

Sometimes it is known that a specif commit or series of commits will break compatibility and in such case it will (under normal circumstances) be mentioned in the commit history (or comments). That is usually also what you can read back on the breaking compatibility user changes wiki page.

If it would be such an easy task to detect breaking commits would you not think that would be a perfect job for something like ChatGPT ? 

[Fred vS]

Sometimes it is known that a specif commit or series of commits will break compatibility and in such case it will (under normal circumstances) be mentioned in the commit history (or comments). That is usually also what you can read back on the breaking compatibility user changes wiki page.

It is this case that I targeted, if such a specif commit or series of commits will break compatibility please add in comment a keyword easy to filter, like "break-possible"
Before all the work needed to update wikis and histories.

[Fred vS]

If it would be such an easy task to detect breaking commits would you not think that would be a perfect job for something like ChatGPT ? 

Of course I asked this to ChatGPT before to ask it here 

Me:

Q: show me the commits done in fpc main source that breaks compatibility with fpc 3.2.2

AI:

A: As an AI language model, I do not have access to the specific commits made to the FPC main source code or any version control system, and I cannot perform a detailed analysis of the codebase to determine which changes may have broken compatibility with FPC 3.2.2.

However, you can view the FPC changelog to see a list of all the changes that have been made to the codebase between different versions, including any changes that may have broken compatibility with earlier versions. You can find the changelog for FPC 3.2.4, the latest stable version at the time of this writing, on the FPC website at https://www.freepascal.org/docs-html/rtl/changelog_3_2_4.html.

Alternatively, you can consult the FPC documentation or reach out to the FPC community for more specific information on compatibility issues between different versions of the compiler.

Nice to know that FPC 3.2.4 is just released at the time of this writing...

[Thaddy]

Some people just should not use trunk. This is really disturbing asking for documentation on trunk. That is plain silly. Use stable instead. And as far I am concerned never ask that question again.

[TRon]

It is this case that I targeted, if such a specif commit or series of commits will break compatibility please add in comment a keyword easy to filter, like "break-possible"
Before all the work needed to update wikis and histories.

As PascalDragon said: it is at the discretion of the developer/team (and I am not going to argue against that).

[Thaddy]

You don't have to argue against it. The documentation is maintained to be released with the next official release. Do not worry about that. It is just that features in trunk may appear and subsequently also disappear.
If a feature is announced, you are usually safe to use that, but not all features ARE announced because they may be incomplete and transfered to the next trunk/main.
There is no way around it: use the git features will do.

Also note that we FPC users are lucky that we can always see the status of a yet to be released version, whereas most software development relies on alpha and beta testers.
Using trunk you are an alpha tester. When there is an announcement for release candidate you can become a beta tester.
If you want to follow trunk, OK, but realize what you are doing. Most people don't (Like Fred)
To follow trunk you MUST do a daily check on the revision and update when necessary and be able to compile trunk yourself. There may be moments that even fpcupdeluxe can't help you.
And even then you may run into trouble if somebody just committed a feature or fix...
<sigh, all this is so difficult to understand? >

Very angry Thaddy.