Can be assumed the New Publiccode.yml Editor 2.x in Production (https://publiccode-editor.developers.italia.it) will update on new official Releases?

[itamair]

It looks in the last weeks the Production version of the Publiccode.yml Editor
available here: https://publiccode-editor.developers.italia.it
was accidentally deployed on the Develop branch (as confirmed here: #349 (comment))
and it was continuously aligned / updated on each new commits on that branch (without any new Tag / Release),
that looks a pretty un-usual (and not best) practice.

Now that a new 2.0 release has been issued (on the same develop branch)
could we (the OSS community) assume that new versions of the Publiccode.yml Editor will be deployed ONLY according to new Tags / Releases?

Or are you still updating (and going to update) the Production versions with the HEAD of the Develop branch?

I strongly feel the Publiccode.yml Editor Production version should always follow expected production deployments practices, that means be tight to a new official Release / Tag.
(and much better if it could be clearly mentioned into its Front End, as already required here: #313)

[valeriocomo]

hi @itamair .

Thank you for your report.

Today, I released version 2.0.1.

This version is tagged v2.0.1 and it's deployed from the main branch.

We are committed to ship new version of Public Code Editor in a more consistent way.

[itamair]

Thanks @valeriocomo for this feedback.
Indeed the whole publiccode.yml metadata standard OSS community (that is Italian and not only italian) relies (nowadays) on this Publiccode.yml Editor for generating and updating (& validating) its publbiccode.yml files ... and in a solid and qualitative way.

Yes, I can see that new v.2.0.1 tag was deployed on the main branch,
and you say we should assume it reflects (and it will reflect) this production web url version: https://publiccode-editor.developers.italia.it/

Also I can see the embedded publiccode.yml file softwareVersion property (here) was updated accordingly ...

Nice!

Important note/warning/recommendation: We assume (hopefully) that you will not push any new commits directly into this main (production) branch without generating a new tag/release for it... (so as to be in line with good distribution practices and ensure that production evolution always reflects a new release), and also the new release will always be reflected in the softwareVersion property of the publiccode.yml file.

[itamair]

PS: ... and still also this Missing release version in the Web UI enhancement would be a very nice to have, imho.

[valeriocomo]

Hi @itamair .

I know the importance of Public Code Editor in the ecosystem and we work with best effort to improve it. The road is not perfectly paved yet but done is better than perfect.

You must assume that production version is v2.0.1 and it's GA at this link.

You noticed that publiccode.yml has been updated accordingly to package.json version property and the tag version.
I should mention that CHANGELOG.md has been updated with the latest fixes and features released.

I will work to automate these steps.

In general, we will reconsider the branching strategy and how the main branch will suppose to work.

Do you suggest to adopt a git-flow-like branching strategy?

In the end, I'll queue #313 in the list of the activity.

[itamair]

hi @valeriocomo thanks for your further feedback :-)

Well, yes ... GitFlow Workflow (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) might work, sure, why not?
Or whatever you prefer also.
Something that should established that the Production branch (or Main branch, as you want to call it)
should not receive new commits without new associated Tags / (fully QAed Official Releases)
as you can see from the attached schema, still taken from the previous Atlassian page.

These are foundational / basic GIT Deployment workflows / proper practices.
It goes without saying / implied that you should also adopt / use a Develop branch (as it looks you do) to merge all new MRs / Features into, and of course you shouldn't do that directly into the Production / Main branch, eh!

You should only merge progresses from the Develop into Production / Main branch only when you are confident to deploy a new tag / Release into it!
BUT still before doing that you should prepare the Develop branch with a last new commit (into it) to update the publiccode.yml file with updated softwareVersion and releaseDate properties.

Makes sense?

[valeriocomo]

@itamair I knew git flow and its branch model very well. I have largely adopted it in a corporate context in the past.
To be more meticulous, main branch must merge from a release branch or an hotfix branch.
We are considering to adopt a release-like branch with aims to:

• run build pipeline
• automate all the release steps (version bumping, changelog update, publiccode.yml update)
• leave open a possibility to change something manually (ex. a typo in the changelog)

We will working on it in the next weeks.
Thanks for your suggestions.