Remove "date_time_created" from JSON

[pml-lang]

Remove "date_time_created" from JSON

[pml-lang]

Good suggestion! Thanks.

I have:

• removed attribute date_time_created
• added attribute pml_release_date (i.e. the date at which the PML version was created)

So, instead of:

"pml_version":"1.5.0",
"date_time_created":"2021-07-12T11:05+0700",

... the file will contain:

"pml_version":"1.5.0",
"pml_release_date":"2021-06-08",

Here is an example of the new file: pml_tags.zip

The change will be included in version 2.0.

I will close this issue after version 2.0. is published.

[tajmone]

Not yet, but I'll have a look at that. Thanks for the tip.

I strongly suggest that you look into all the powerful features that GitHub offers as an added service layer for project management and collaborative editing — Dashboard functionality, Projects and Milestones, etc.

By enabling automated kanban with review in Project boards, and using autolinked Issue-references, along with Milestones and labels, you'll be able to optimize the whole workflow for yourself and your collaborators.

Whilst all of these features are optional "added bonuses" to the workflow, not adopting them early on can lead to difficulties in integrating them at a later stage (beside ending up with a partially covered workflow).

GitHub is releasing tons of new features lately, especially related to GitHub Actions and automation in general. Since PML and pXML revolve around multiple repositories, and across more than one organization, you might also want to look into GitHub Teams as a means to gain fine-control over how these projects are all linked together.

You can, for example, create detached Project boards for PML, thus centralizing discussions and planning, instead of having them scattered across multiple repositories, and at the same time keep localized control over each repository.

I know that this requires lots of documentation reading, but early adoption of a well-organized workflow is going to pay-off in the long term, especially in terms of ease of collaboration for contributors, and also optimize production times on your side; so it's worth it.

[tajmone]

Great! And thanks for providing the JSON files previews — I often use them locally to carry out some tests with Mustache.

I will close this issue after version 2.0. is published.

Don't you use autolinked Issue-references in commits to automatically close Issues? E.g. closes #45 would automatically close this Issue when the commit is merged into main branch, but leave the Issue open until it's in another branch.

[pml-lang]

Don't you use autolinked Issue-references in commits to automatically close Issues?

Not yet, but I'll have a look at that. Thanks for the tip.

[pml-lang]

Thanks a lot for this additional info. After publishing PML 2 I should have a closer look at this. I'm a big fan of on-click automation.

[pml-lang]

The change will be included in version 2.0.

Now done in version 2.0.0

[tajmone]

Now done in version 2.0.0

You mean in 2.0.1? I still see the release date in the current JSON output.

[pml-lang]

You mean in 2.0.1?

It's done in 2.0.0 (but the latest public version is 2.1.0)

I still see the release date in the current JSON output.

Yes, because we agreed to:

remove attribute date_time_created
add attribute pml_release_date (i.e. the date at which the PML version was created)

I just tried it out (with version 2.1.0, but it should work the same in version 2.0.0). I think it works correctly (unless I misunderstand your message). I get this result:

{
    "pml_tags":{
        "pml_version":"2.1.0",
        "pml_release_date":"2021-09-09",
        "tags":[
        ...

Note, however, that the release date of version 2.1.0 is 2021-09-09, although I uploaded it yesterday on 2021-09-08.

[tajmone]

Yes, because we agreed to:

You're right. Sorry. I've got a very bad toothache (swollen face and fever), so I have difficulties focusing in these days.

[pml-lang]

I've got a very bad toothache

I wish you a speedy recovery.