Release tarballs are currently renamed (without changing the contents): apache-fineract-src-1.12.1.tar.gz becomes apache-fineract-1.12.1-src.tar.gz . The former matches the exploded directory name, the latter does not. The difference is subtle but meaningful... I strongly prefer the former because it's less surprising / more common, and easier to work with from scripts.
There's no functional difference, this should only impact aesthetics.
I did also shorten `binary` to `bin` so release artifact name lengths match.
* fix various typos, spacing, formatting issues
* fix links to legacy docs in API docs
* update keycloak oauth dev instructions
* update default oauth URL for latest Keycloak
* use consistent quoting in oauth docs (single quotes)
* use asciidoc auto-enumerated lists whenever possible
* migrate security topics from readme into asciidoc: oauth, 2FA, HTTPS
* move :hardbreaks: setting to config file so all config settings are in one place. (I think it's fine that `license.adoc` will use hardbreaks -- that's how the plain text version is formatted so it should look more familiar)
* add intro to security chapter
* migrate in Securing Fineract wiki content from https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract
* just say "oauth" (not "oauth2") to conform terminology throughout docs -- OAuth 2.0 is just the latest version
* cross-ref HTTPS section from Securing Fineract
* reposition hardening options as tips
* see also: https://lists.apache.org/thread/81qdxttffp6wn23c48zvk93hc13373qv
* simplify/clarify example oauth curl requests
* Testing just now and I didn't need --location.
* Also I imagine folks will need --insecure with the self-signed default cert in dev.
* don't change default oauth URL
* no surprises for existing deployments
* clarifies the keycloak v26 example
* docs: link directly to FINERACT-873 and shorten it for brevity / clarity
* fineract plugin:
* print email, don't send (WIP, but I might keep this... I prefer manually sending emails for now.)
* support different release date and release branch date
I originally modified EmailService (disabling the actual email sending by just commenting it out) but I reverted that change per discussion with Ádám Sághy. You won't see this in the squashed final commit so I'm mentioning it here for posterity.
Ádám wrote:
> Is there a reason to remove the email sending?
I replied:
> Great question. I did think about this for a bit. I should have been more transparent about my intent. Allow me to explain.
>
> For the 1.12.0 release process I used the groovy code to generate email templates, but I wanted to edit the emails before sending so I disabled this line, and intentionally left it so, figuring I'd be the one using and [hopefully minimally] maintaining it for now.
>
> The Fineract (release) plugin appears to be more or less unmaintained for about 2 1/2 years now (save the semiautomated dependency updates). Looking at the code and history, I assumed I was the only one that would be using it now and in the near future. It also struck me how most everything it does is primarily to work around antiquated Apache release process steps that are not necessarily what we want for Fineract. Personally I think the Fineract release plugin should be simply replaced by a better release process.
>
> I think I'll add a comment there, and of course I welcome your feedback.
>
> Anyway yeah, my intent here was simply to do the simplest, safest, and most useful change here so I could keep this release plugin limping along until we improve the release process itself. No disrespect to @vidakovic and @vorburger and whomever else poured love into this code over the years. Perhaps the options for releasing Apache code have improved since then?
>
> Today we can of course do better (e.g. just let GitHub help us release with far fewer clicks/steps).
>
> Also I am not proposing we change the release process today or even soon. Maybe in a quarter or two I'll propose changes, if/when there seems to be political will around that.
Ádám replied:
> hmm... i am not particularly mind if you are reworking the release process, but i think having a "send" step which was meant to sending a mail but now the actual sending got commented out is misleading, no?
I replied:
> Yep, you're right. I think I'll just back out this change because I agree with you it's bad to just leave the send() call commented out without any other changes.
* don't bother making MD5 files, they aren't necessary
* step12 changed, stub it out and reference FINERACT-1817 for future improvements (looks like svn mv is not yet supported)
* use latest vote message template, based on https://lists.apache.org/thread/cs5t0ho39ktg2jxr74dqd7fg9nyfcz3k
* use more explicit form of `git push` to push release tag, see https://stackoverflow.com/questions/5195859/how-do-you-push-a-tag-to-a-remote-repository-using-git
* use consistent language re: tarball, file, artifact, release candidate
* fix some source listings that shouldn't be using macro expansion: this messes up URLs (hides scheme)
* fix asciidoc link to FINERACT-1229
* clean up copyright years: use variable properly and remove unnecessary extra copyright in preface (it appears directly above, in the license)
* de-indent URL in apache license -- this makes the link clickable in rendered HTML and PDF asciidoc outputs
* disable broken fineract-client API asciidoc include
* this has a side effect of removing ~1,200 pages from the PDF
* remove duplicated/outdated text, reduce sources of truth
* link to current FAQ
* introduction is all references now... it was way out of date and also needed formatting fixes
* unset `show-link-uri` to improve PDF rendering
* remove unnecessary/unused `.asciidoctorconfig` file
- [x] New read only properties and environment variables
- [x] Run only when read only password, read only username and schema name is null
- [x] Update and encrypt the password
- [x] Doc properties update
