Deprecations

[roigcarlo]

Dear @KratosMultiphysics/all after speaking @armingeiser and @maceligueta we realized that it is not always easy to keep track of disruptive changes that are going to be merged into Kratos.

In order to be more clear about this, we have created a project Deprecations where we are going to update the status of the PR which introduce those changes.

The PR will be organized in several columns:

• Already Done: Changes that have already been merged to the Master

• Upcoming: (<1 Month) This PR will be merged into kratos in less than a month. If possible, before entering this column the proper deprecation warning (when posible) will be already merged in the core.

• Mid Term: (1 - 3 Months) This changes are planed and have already being developed, but are not ready to be merged.

• Long Term: (>3 Months) These are proposals that are not actively being developed or will not be merged in a near future.

Also a list of the upcoming changes will be printed at the end of the configure while compiling Kratos.

Our aim with this is to be more transparent about the future of the code and make it easy to be able to comment and follow the progress such PR's.

[pooyan-dadvand]

@philbucher you cannot deprecate the issue of deprecation on the first day! :wink:

[maceligueta]

Thanks guys. Will this system notify everyone when something is added? Even if we are not following the issue or pr? Or we must check the lists of the project regularly?

[loumalouomega]

Thanks guys. Will this system notify everyone when something is added? Even if we are not following the issue or pr? Or we must check the lists of the project regularly?

we should post a feature list in the releases...

[loumalouomega]

Thanks guys. Will this system notify everyone when something is added? Even if we are not following the issue or pr? Or we must check the lists of the project regularly?

we should post a feature list in the releases...

*changelog

[roigcarlo]

@maceligueta I think you can subscribe to the project, but it won't be automatic.

@loumalouomega Yes, with this it will also be easier to make a changelog.

[RiccardoRossi]

@maceligueta note thowever that we will modify the cmakelist so that a message about upcoming changes appears at the end of the configuration (as you proposed)

[maceligueta]

I just wanted to contribute making you note that a significant part of the Kratos Community communicates with the rest of the Community exclusively through 'git pull' and only their own PR's on the GitHub website. Many deprecations in the past adopted solutions which worked quite well, even with these limitations. Many of them through compilation-time warnings. If they are not enough, we can always reference 'all' (as long as the team 'all' is up to date).