summaryrefslogtreecommitdiff
path: root/NEWS
blob: 7857290075988373c45c8175348c24ce22c5dd97 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
-*- org -*-
#+TITLE: guile-email NEWS – History of user-visible changes

Copyright © 2019, 2023 Arun Isaac <arunisaac@systemreboot.net>

Please send guile-email bug reports to guile-email@systemreboot.net

* Changes in 0.3.1 (since 0.3.0)
** Support non-standard parentheses in email address names
RFC5322 forbids parentheses characters in email address
names. Previously, parse-email-address would fail on such non-standard
email addresses. Now, we tolerate them.

* Changes in 0.3.0 (since 0.2.2)
** Support obsolete syntax
[[https://tools.ietf.org/html/rfc5322#section-4][Obsolete syntax]] described in RFC5322 is now supported.

** Reimplement (email base64) from scratch
The (email base64) was originally copied from GNU Guix. Now, it has
been reimplemented from scratch.

** Quit the autotools build system
We move away from the autotools build system to a hand-written
Makefiles. It's simpler and good enough for a small project like
guile-email.

** Noteworthy bug fixes
*** Do not rely on bytevector->string throwing an expection with empty bytevector
Passing an empty bytevector and an invalid charset to
bytevector->string no longer raises an exception since Guile commit
5ea8c69e9153a970952bf6f0b32c4fad6a28e839. This caused guile-email
tests to fail on Guile 3.0.7. We no longer rely on this behavior.
https://lists.systemreboot.net/guile-email/87mtnv1r2p.fsf@gnu.org/
*** Support CR LF sequences in quoted-printable encoding
Earlier, only LF characters where accepted in quoted-printable encoding.
https://lists.systemreboot.net/guile-email/20230103121942.10497-1-whatson@tailcall.au/
*** Support Date fields with missing seconds
The seconds field is optional. Respect that.
https://lists.systemreboot.net/guile-email/20230105103324.4396-1-whatson@tailcall.au/
*** Assume application/octet-stream if Content-Transfer-Encoding is unrecognized
§6.4 of RFC2045 specifies that any entity with an unrecognized
Content-Transfer-Encoding must be treated as if it has a Content-Type
of "application/octet-stream", regardless of what the Content-Type
header field actually says.
*** Handle Received headers with two tokens but no timestamp

* Changes in 0.2.2 (since 0.2.1)
** Noteworthy bug fixes
*** Tolerate decoding errors in MIME encoded words
https://lists.systemreboot.net/archives/guile-email/2019/000021.html
*** Tolerate invalid charset
https://lists.systemreboot.net/archives/guile-email/2019/000024.html
*** Tolerate decoding errors in body
*** Prevent duplicate parameters in Content-Type header
*** Return Keywords header as a list
*** Handle blank Subject header
https://lists.systemreboot.net/archives/guile-email/2019/000028.html

** Other
*** Disregard order in comparison of email headers in tests
*** Directory local variables for editing guile-email code
*** Implement custom test runner group begin and end functions
*** Support upcoming guile 3.0
https://lists.systemreboot.net/archives/guile-email/2019/000033.html
*** Log colorized test results to stderr while running them

* Changes in 0.2.1 (since 0.2.0)
** Noteworthy bug fixes
*** Tolerate non-ASCII characters in headers
https://lists.systemreboot.net/archives/guile-email/2019/000009.html
*** Install compiled go files in libdir
https://issues.guix.info/issue/37409

* Changes in 0.2.0 (since 0.1.0)
** API changes
*** parse-email and parse-email-body accept byevectors
Prior to this, parse-email and parse-email-body would accept email in
the form of a string. A string is constrained to use the same encoding
for all its characters whereas an email can have characters encoded
using different encoding schemes. Therefore, it is more correct that
parse-email and parse-email-body deals with bytevectors instead of
strings. Support for parse-email and parse-email-body accepting is
retained for backward compatibility, but it may be deprecated in the
future.

** Noteworthy bug fixes
*** Decode email with multiple encoding schemes
https://lists.systemreboot.net/archives/guile-email/2019/000001.html
*** Decode MIME encoded words in the Subject header
https://lists.systemreboot.net/archives/guile-email/2019/000002.html
*** Decode MIME entities without headers

** Other
*** Documentation
A first version of the texinfo documentation is now ready.
*** guile-email@systemreboot.net mailing list
We now have a mailing list at guile-email@systemreboot.net
https://lists.systemreboot.net/listinfo/guile-email
*** guile-email.systemreboot.net website
We now have a simple one-page website for guile-email at
[[https://guile-email.systemreboot.net/][guile-email.systemreboot.net]]