Release Pelican 4.0

[justinmayer]

This issue tracks the release of Pelican 4.0.

[askpatrickw]

I was just doing some site updates today and thought I'd ask if there was anything we can do to help get an update out.

Thanks so much for Pelican!

[justinmayer]

Hey Patrick! First of all, thank you so much for the kind words. But more importantly, thank you for the perfect way you inquired about this. While many are (understandably) inclined to ask about planned release dates, you instead opted to ask how you might help get a release issued — music to any project maintainer's ears! 😁

While I could release Pelican 3.8 from master in its current form, I think it would be worthwhile to take this opportunity to see what else we can accomplish before release. You know, a mini-sprint. So possible ways to help could include:

• Reviewing items marked for the Pelican 3.8 milestone and helping to determine what should be done.
• Similarly, reviewing the existing pull requests to evaluate their relevance/importance, test them, provide input when additional tests/docs are needed, etc.
• Review the existing issue queue and see what can be done to pare the list down.
• For any issues/PRs that you feel are critical and should really be included in 3.8, comment on them to that effect so I can add them to the 3.8 milestone.

Thank you in advance for any assistance you can provide. Looking forward to a great release!

[jorgesumle]

Some things may not work after the upgrade (for example, the make serve instruction from Makefiles generated with old Pelican versions). Ideally, we should talk about that in a blog post and give advice on how to upgrade.

[justinmayer]

@jorgesumle: Agreed. Would you be interested in starting that process by adding a stub/draft release post in the Pelican Blog repository?

[jorgesumle]

Would you be interested in starting that process by adding a stub/draft release post in the Pelican Blog repository?

Sure

[jorgesumle]

Would you be interested in starting that process by adding a stub/draft release post in the Pelican Blog repository?
Sure

Sorry, but I didn't know about the lack of license of the Pelican blog. I'm against this kind of restrictive copyright, so unless I can submit my contribution under a libre culture license, I won't be working on that.

[justinmayer]

Unless there is sufficient reason to do otherwise, I am inclined to release Pelican 3.8, based on current master, within the next few days. So if anyone feels there is something outstanding they want to see included in this release, now is the time to take appropriate action to that effect. Just wanted to communicate that and gives folks a heads-up. 😊

[mosra]

@justinmayer Wanted to get to testing current master much earlier, but didn't have time until now. Sorry.

• I found an issue with Fix metadata intrasite links #2226 / Fix metadata intrasite links #2288 where replacement of metadata links is somehow depending on order in which pages are processed (so links referencing pages that are not yet processed are reported as Unable to find). Not good. Will investigate and try to post a patch later today.

• One of my plugins (m.metadata) is not requiring page title in reST sources but since Multiple reST headers yields "could not find information about 'date'" #2311, Pelican warns me that this is illegal. Not sure what to do here -- what about requiring at most one title instead of exactly one title? Technically, I could see title being optional also in case of pages (for example when using a custom template for a particular page).

• This is what I get with current master when running the old make devserver (i.e., with a makefile from before develop_server.sh was removed):

  Starting up Pelican and HTTP server
  /usr/lib/python3.6/runpy.py:125: RuntimeWarning: 'pelican.server' found in sys.modules after import of package 'pelican', but prior to execution of 'pelican.server'; this may result in unpredictable behaviour
    warn(RuntimeWarning(msg))
  usage: server.py [-h] [--ssl] [--cert [CERT]] [--key [KEY]]
                   [port] [server] path
  server.py: error: the following arguments are required: path
  

  (Related SO thread.) Not sure if/how this is important, but that led me to thinking there should be some warning or message, suggesting users to upgrade their workflow / makefiles. How's that usually done, by the way? Running pelican quickstart again?

• Since the autoreload+server is now part of Pelican, I realized I also don't need any Makefile anymore, since I only ever used make devserver and make publish. That's now doable directly with Pelican, but I need to say either pelican -s publishconf.py or pelican -D -l -r and that's kinda non-intuitive / hard to remember. What about providing top-level pelican --devserver / pelican --publish commands that alias the above? I could provide a patch for this. I assume I'm not the only user who would find this useful, moreover this would make the whole workflow look much more self-contained.

[avaris]

I found an issue with #2226 / #2288 where replacement of metadata links is somehow depending on order in which pages are processed (so links referencing pages that are not yet processed are reported as Unable to find). Not good. Will investigate and try to post a patch later today.

Commented there.

One of my plugins (m.metadata) is not requiring page title in reST sources but since #2311, Pelican warns me that this is illegal. Not sure what to do here -- what about requiring at most one title instead of exactly one title? Technically, I could see title being optional also in case of pages (for example when using a custom template for a particular page).

This is less about titles but more about metadata. reST requires a particular layout to be able to parse metadata. All content in core pelican requires a title. So I'm fine with that warning. I'd suggest suppressing warnings in your plugin if you want.

This is what I get with current master when running the old make devserver (i.e., with a makefile from before develop_server.sh was removed):

Starting up Pelican and HTTP server
/usr/lib/python3.6/runpy.py:125: RuntimeWarning: 'pelican.server' found in sys.modules after import of package 'pelican', but prior to execution of 'pelican.server'; this may result in unpredictable behaviour
  warn(RuntimeWarning(msg))
usage: server.py [-h] [--ssl] [--cert [CERT]] [--key [KEY]]
                 [port] [server] path
server.py: error: the following arguments are required: path

(Related SO thread.) Not sure if/how this is important, but that led me to thinking there should be some warning or message, suggesting users to upgrade their workflow / makefiles. How's that usually done, by the way? Running pelican quickstart again?

I failed to understand the issue from a quick glance :). I'll take a deeper look later.

Since the autoreload+server is now part of Pelican, I realized I also don't need any Makefile anymore, since I only ever used make devserver and make publish. That's now doable directly with Pelican, but I need to say either pelican -s publishconf.py or pelican -D -l -r and that's kinda non-intuitive / hard to remember. What about providing top-level pelican --devserver / pelican --publish commands that alias the above? I could provide a patch for this. I assume I'm not the only user who would find this useful, moreover this would make the whole workflow look much more self-contained.

Disagree. I'd rather have people spell out individual options instead of providing shortcuts with defaults that might not fit everybody.

How about defining aliases in the shell for yourself? :)

PS: IMO, pelican --debug --listen --autoreload is reasonably intuitive.

[askpatrickw]

I'm a little late to the party, but just wanted to chime in and say it's definitely the right move to release what you have. 👍

[oulenz]

I feel we should get the pandoc 2 fix in before 3.8 (PR #2366 ✔️), since I believe that otherwise, both pelican-import and running the full test suite are broken.

Of lesser importance, I filed a number of pull requests which I had really hoped to get merged before 3.8:

#2309 (Identify translations per category if articles share the same slug) ✔️
#2324 (correct suffix order in ComplexHTTPRequestHandler) ✔️
#2326 (control slug substitutions from settings with regex) ✔️
#2375 (tweak paginator to accomodate {slug}.html patterns) ✔️
#2381 (automatically copy linked static files) ✔️
#2384 (control pagination per template) ✔️

[justinmayer]

I won't be able to dig into the aforementioned PRs in the time I currently have available, so I've asked folks in the Pelican community if they could possible take a look.

Regarding the Pandoc 2 issue, I agree it would be nice to fix it, and I hope that PR is ready in time. I suggest folks test it now, if possible, and ensure it's ready to go. Otherwise a fix will have to be included in a subsequent point release.

[oulenz]

Thanks @justinmayer. I wish that we could wrap up #2326 ✔️ in particular, since it's already been reviewed by @avaris, so potentially just needs a final sign-off and squash, and maybe a rebase. It's quite big (including some general clean-up), so there's a risk that rebasing becomes more tricky as other commits are added to the master branch. In addition, I have a plugin that handles multiple categories (e.g. coming from a wordpress import) that I am holding off from releasing because it assumes this PR.

Please do not read this as a complaint. I understand that everyone involved has little time to spare and if this doesn't make it into 3.8 then so be it.

[justinmayer]

Hi folks. I'm determined to issue a new release within the next two weeks — preferably no later than the 13th of November. So anything that's not ready by that time will probably be deferred until a subsequent release. Thanks to @oulenz, all the other contributors with PRs in the queue, and @getpelican/reviewers for anything you can do to assist over the next two weeks. Much appreciated! 😁

[mosra]

@justinmayer I'm aware that I'm blocking a few issues/PRs and I'm trying to reshuffle priorities to be able to get to them hopefully close to end of this week. Sorry, too much to do, as always 😅

[justinmayer]

@mosra: No worries. Really appreciate your assistance and look forward to your re-emergence. ☺️

@avaris: Many thanks for your tireless efforts in reviewing pull requests, which has enabled a lot of progress this week! Do you see any other items in the 3.8 milestone that are worthy of reviewing for potential inclusion in the next release?

[justinmayer]

I plan to issue a new Pelican release within the next 48 hours. Looking at the 240+ commits made to master since the last release, I'm now wondering whether we should name this release “4.0”.

It's difficult to apply semantic versioning to Pelican — despite best efforts at backwards compatibility, every release has the potential to break something for someone. And with this many changes, one might say that potential is higher than normal. In the end, I suppose I'm just not overly concerned with what incrementing the major digit will signify to folks.

To that end, any thoughts on naming this “4.0” instead of “3.8”?

[mosra]

I was not around in the pre-3.7 days (and so I don't know how big the jump was from 3.6 to 3.7) but I don't see 3.8 as "just a minor update", it deprecates quite some things and replaces them with better alternatives. For me personally, just the removal of develop_server.sh alone in favor of Pelican handling everything itself is enough to name it 4.0.

[avaris]

I was imagining 4.0 as a complete overhaul of the core code and would ultimately break all plugins 😈. But, oh well, I can save that for 5.0 i guess.

[justinmayer]

I also imagined bigger things for 4.0, including moving plugins and themes to individual repositories, making them pip-installable, et cetera. Ultimately, however, I think those endeavors can wait to be blessed with the 5.0 moniker.

[ssteinerx]

+1 on the 4.0 label because:

1. It's been a long time since 3.7
2. There are significant and probably breaking changes
3. The x.0 release implies an x.1 release very soon to fix the oddities that invariable attend a x.0 release
4. It will be easier to add some of the pending features as .1, .2 in smaller chunks whereas 3.8's only got so far to go which might mean trying to add too much before 3.9. I think smaller chunks & more frequent releases would be very desirable.

[justinmayer]

Pelican 4.0 has been released. Many thanks to @oulenz, @mosra, @avaris, @ingwinlu, @jorgesumle, @MinchinWeb, @josch, @Lucas-C, and all the other amazing folks who contributed to this endeavor and helped make this possible. You rock! 🚀 https://blog.getpelican.com/pelican-4.0-released.html