Create 5.0 directory

[ike]

A 5.0 directory should be created to hold new work, and 4.0 should reflect the state of the last release.

[elarlang]

I think we need Josh here, as he has been our git guru and vision guy.

[jmanico]

This is very straight forward. I got this. Unless someone else steps up I’m taking lead on the 5.0 release.

[jmanico]

I think we need Josh here, as he has been our git guru and vision guy.

I am the new git guru and new vision guy. Let's move forward folks. We're going to use Josh's vision moving forward and expand on it. Josh is busy and we need someone else to take this on. That is me and our amazing volunteer @ike

[elarlang]

Well, all the commits and PR merges should be on hold till 5.0 is created, otherwise it will be proper mess :)

[ike]

100%, that would be a real snarl

[jmanico]

There are very few PR’s - I’m away from my computer today. Elar pleas go ahead and merge as you see fit! You have merge access, right?

[elarlang]

No, I don't have, but I think it's not something which can not wait few days.

[tghosth]

Whilst I don't want to stop momentum here, especially as I have been so inactive, I want to make sure this operation is done a little carefully and that it is fully understood what is being done. Currently there is a large PR which seems to be doing a lot so I want to try and divide it up into stages.

In particular, given that we will be losing simple version history when we move files from one folder to another, I want it clearly document how and when the move happened to make that process easier.

Also, there is a 4.0.3 version which has a few very small changes but if we are freezing the 4.0 folder then I think we should release 4.0.3 and freeze to that version.

As such, I think we need to follow the following process with a different PR for each stage:

• Release v4.0.3 (I will commit to doing this, this week)
• Create a new v5.0 directory which contains the bleeding edge files from 4.0 including markdown files, code files but not the PDF/DOCX or any other outputs and doesn't include translations. I think folder structure should be the same though (@elarlang any other thoughts).
• Roll the 4.0 folder back to v4.0.3. We should make a note of the commit before this is done and the commit after this is done so that it is easier to trace back history.

@ike @jmanico any comments, anything I have missed?

From my perspective, the Spanish translation can still be included in the 4.0.2 branch or 4.0.3 branch and then eventually 4.0 folder on master and it can be added whenever.

[ike]

I think this is a great plan. It will be much harder to mess up future work by taking these stages in order. I will change #1080 to reflect stage two:

Create a new v5.0 directory which contains the bleeding edge files from 4.0 including markdown files, code files but not the PDF/DOCX

Agree that with this plan the Spanish translation can be included whenever.

[elarlang]

Agree with folder structure, I shared the same opinion in commenting related PR:
#1080 (comment)

[jmanico]

Josh, This is fantastic. Thank you!

[elarlang]

Discussed directly with @tghosth his vision, and I put my own tasks as pre-condition for releasing (or decision to not release) v4.0.3:

• re-check and validate all current labels and modifications in bleeding edge
• get abstract overview, how many requirements could be updated without "breaking changes"
• decision place - is it worth releasing v4.0.3 or we can be happy to leave v4.0.2 as 4.0/ folder content.

[elarlang]

Do I understand correctly that we drop current PR (#1080) and we go with plan like @tghosth described?

Otherwise I think we are a bit in dead-lock situation. I would like to make fixes to labels, but then it makes extra work for every other step.

[jmanico]

Josh did say he would cut the 4.03 release in a week. Then we can freeze the 4.0 folder at the 4.03 release and move our work to 5.0. Let's give Josh that week and then we can move from there. There is no dead-lock.

[elarlang]

Please re-check my previous comments - my work is pre-conditions for Josh, without that we can not move anyway.

[jmanico]

I assume these three things were part of Josh's rollout to 4.03.

[jmanico]

I personally suggest we abort 4.03 and get ready for 5 and if we do not make progress in a week I plan to move in that direction.

[ike]

Do I understand correctly that we drop current PR (#1080) and we go with plan like @tghosth described?

This was my understanding, yes. This PR (#1080) will become either step 2 or step 3 of the plan.

[timpotter87]

Please don't abort 4.0.3. The alignment of password length to 8 characters which matches NIST and Mobile standards is desperately needed.

[elarlang]

If is a bit ottopic here... but.
There is no version v4.0.3 yet and nothing to abort. Requirement 2.1.1 is modified in bleeding edge (not released / working document) and I'm not sure - would it be allowed changing password minimum length requirement from 12 to 8 (because it feels breaking change).

[ike]

@tghosth -- could this method be used to help retain the continuity of the new 5.0 directory? https://stackoverflow.com/a/44036771

[tghosth]

@ike that would be amazing. Is that something you can do in a PR?

@jmanico
General update, elar has done a lot of work to gather content for 4.0.3 so as to make it a more meaningful update and we are planning to start the update in the next few days. Apologies to the delay and bear with us, we are going to fast track this.

[jmanico]

There is no need to apologize. Elar is doing great work and I’ll be patient. Thank you both!

[ike]

@tghosth yes, absolutely! After the 4.0.3 release, I will use this method to create the 5.0 directory pull request.

[cmlh]

Quoting @tghosth below:

@jmanico General update, elar has done a lot of work to gather content for 4.0.3 so as to make it a more meaningful update and we are planning to start the update in the next few days. Apologies to the delay and bear with us, we are going to fast track this.

If @elarlang creates an annotated tag then deletes the same branch then this will create a detached head effectively freezing changes until the head is reattached when @elarlang pushes upstream.

If that is too complex then https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches is simpler but not as foolproof.

[ike]

@cmlh -- yeah! We don't want to have a detatched head, which is why we're doing each bit in order, based on the plan @tghosth outlined. This should maintain the head, since we'll be doing each bit of work in sequence. Protecting release branches and master could be good in general too.

Basically:

• Bleeding edge will become 5.0
• 4.0 directory will become the 4.0.3 release
• Commit after freezing 4.0 directory and moving bleeding edge to 5.0 will be tagged as 4.0.3

Hope that's clear.

[jmanico]

I think this is a great plan, Ike!

[tghosth]

We are almost ready to release 4.0.3, you can see the diff with 4.0.2 here:
#1104

If anyone has comments, now is the time :)

[elarlang]

@ike and @tghosth - just in case asking it - is your described technical scenario suitable for potential v4.0.4 release in the future?

[ike]

@elarlang yes, continued releases could happen in the 4.0 directory.

[cmlh]

Is there a roadmap of the upcoming changes between the 4.0.3 and 5?

How will #1104 be documented within the 4.0.3 minor release? A git-shortlog may be the easiest.

Is there an SLA of when the language translations may occur even if this is documented as "best effort"?

Can @OWASP GPG sign the git release tag?

Is the use of git blame reproducible as a test case so the decision leading to each change is transparent?

The above should not delay the shipping the 4.0.3 release and can be reconsider at a later date i.e. LGTM 🚀 👍

[ike]

Is the use of git blame reproducible as a test case so the decision leading to each change is transparent?

Yep! All our changes will maintain history, so git blame will work.

[cmlh]

Yep! All our changes will maintain history, so git blame will work.

This is limited to up until the initial creation of the 4.0 directory.

[tghosth]

4.0.3 is released, @ike prepare your PRs :)

[ike]

Woooo! Congrats!

[ike]

Closed with #1117

[tghosth]

Hi @ike, did we not say that we would be keeping the file history when we moved to 5.0? It looks like that is not visible in GitHub...

[ike]

@tghosth -- yes, the history is still there, although Github does not show it. Using the --follow flag, you can see the history on your local copy. This is a feature that has been asked for in Github for a long time.

git log --follow <path>

[tghosth]

Thanks for the response on this @ike. Frustrating that Github doesn't support it 🤦‍♂️