plantuml/plantuml-stdlib

awslib/Mobile/Mobile.puml is black

StevusPrimus opened this issue · 8 comments

StevusPrimus commented

image

@startuml
!include <awslib/AWSCommon>
!include <awslib/Mobile/all.puml>

listsprites
@enduml
Potherca commented

There should be more content after the xS61400000CXWldhpkElMXu0001m in the Mobile.puml file.

By the look of things, whatever caused the breakage (in 82a5108) also broke all.puml.

The-Lum commented

Yes, You are right....
Perhaps we could ask the question to the author of the changes.

@mmajis: We have some questions about your PR:

On awslib/Mobile/Mobile.puml:

Same question on awslib/Mobile/all.puml:

Thanks for your help,
Regards.

mmajis commented

Hi!

Here's the upstream source for the iconset: https://github.com/awslabs/aws-icons-for-plantuml/tree/v10.0/dist

They have breaking changes between releases. In fact it looks like the entire Mobile folder is gone in v11.0 and also in the latest v14.0 release. The icons from the Mobile folder have moved around to different folders like ApplicationIntegration, BusinessApplications, FrontendWebMobile etc.

What happened here was that Mobile.puml and all.puml got overwritten by v10.0 but the other files from v7.0 were left over as they no longer exist in v10.0.

I was trying to avoid breaking old diagrams by leaving the files there but didn't realize that the all.puml imports were going to break for those icons anyway.

One way to clean up would be to remove all the leftover files that are now unreferenced from all.puml in each folder. That would further break diagrams that import the service-specific puml files but we'd stay fully in sync with the upstream iconset.

Another option is to start carefully managing the merging of all.puml files to maintain backwards compatibility when updating to newer upstream icons. That might escalate to a lot of work and duplication of icons in various folders in the stdlib iconset going forward.

Maybe a third option would be to maintain multiple versions of the AWS iconset in the stdlib with some sort of deprecation schedule for old versions?

  • 👍1
arnaudroques commented

Maybe a third option would be to maintain multiple versions of the AWS iconset in the stdlib with some sort of deprecation schedule for old versions?

I think it's the best solution.

So here what I suggest:

  • Let's forget about v7.0
  • Let's rename current awslib directory to awslib10 and remove old v7.0 icons
  • Let's create new awslib14 directory with v14.0 icons
  • We (the PlantUML team) will create a new system of internal symbolic links so that awslib points to awslib14

I am aware that we are breaking compatibility here, and that people may have to rename their !include <awslib/...> to !include <awslib10/...> and that older diagrams with v7.0 icons will also break.

However, in the future, people would be able to choose:

  • either to stick to a specific version (using !include <awslib14/...> for example )
  • or use the last by default (using !include <awslib/...> ) with a risk of issue when upgrading PlantUML version.

And when v15.0 will be released, we will simply create a new awslib15 directory and make awslib linking to it.

Does it make sense?

  • 🚀1
mmajis commented

Sounds good!

arnaudroques commented

Sounds good!

So awslib has been renamed to awslib10. And there is a new awslib pointing to awslib10 now.

@mmajis Could you clean up awslib10 and remove old v7.0 icons there?
If that's easy to do, you may also create a new awslib14 with v14.0.

mmajis commented

Created PRs #64 for awslib10 cleanup and #65 to add awslib14.

  • 👍2
  • 🚀1
The-Lum commented

Hi all,

[This is an Issue Review] 👀
This is now fixed.

Regards.