Mailing List Archive

upgrade to 3.2.1
Back in July I asked about upgrading to 3.1.16 and was counseled to wait
for 3.1.17. So, I waited, but I never upgraded to 3.1.17.

I see that 3.2.1 is released... at least partially.

I need to upgrade to avoid dbmail-pop3d problems in 3.0.2 that I believe
were resolved long ago. Do I have a green light from the developers on
using 3.2.1?

From looking at the UPGRADING document, it appears that the DB schema
auto-updates. So, I don't need to run anything in sql/mysql to update.
Correct?

Thanks,

Lee.
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
Re: upgrade to 3.2.1 [ In reply to ]
Am 17.12.2014 um 00:26 schrieb Lee Howard:
> Back in July I asked about upgrading to 3.1.16 and was counseled to wait
> for 3.1.17. So, I waited, but I never upgraded to 3.1.17.
>
> I see that 3.2.1 is released... at least partially.
>
> I need to upgrade to avoid dbmail-pop3d problems in 3.0.2 that I believe
> were resolved long ago. Do I have a green light from the developers on
> using 3.2.1?
>
> From looking at the UPGRADING document, it appears that the DB schema
> auto-updates. So, I don't need to run anything in sql/mysql to update.
> Correct?

don't get me wrong: nonody but you can give a green light and as for all
major upgrades you need to *test* it before put it in production

so mirror the complete database folder on a test installation and try
the migration - that's the only way to find out if there are migration
issues in your case

it don't help even much if 1000 people confirm a upgrade without any
issue and with your data the scheme migration stops in the middle with a
SQL error (been there due migration to 3.0 and it needed a lot of
cleanups after i was save to migrate the prouction server removing
duplicate records and garbage before)
Re: upgrade to 3.2.1 [ In reply to ]
So after weeks of part-time work resolving dependency issues in the
upgrade (primarily with GMime and Glib, but libevent was also a minor
issue) this evening I upgraded from 3.0.2 to 3.2.2.

I did make a backup of the database, but the schema auto-migration
appears to have worked, things are operational, and I do not notice any
ill effects with the database at this point.

(I'm hoping that the efforts of this upgrade result in no more
situations where clients cannot connect to dbmail-imapd and dbmail-pop3d
services. Whether the problem was in dbmail or in GMime or something
else, I don't know. I didn't have any problems after upgrading only
GMime, but I didn't let dbmail-3.0.2 run long-enough with GMime-2.6.20
to say. Normally I would see one problem every two weeks or so, but
lately it was more-frequent: like once per-week. I only finished the
GMime upgrade on Thursday.)

I quickly hit-upon the dbmail-imapd segfault bug fixed here:

https://github.com/pjstevns/dbmail/commit/edd6179d638d4257d0a669de582f8770370a7364

So, I applied that patch, and it seems to have resolved the crashing
problem.

Upgrade documentation is a concern for me, though...

The UPGRADING document and the sample dbmail.conf file explain that
[dburi] has deprecated [driver], [host], [sqlport], [sqlsocket], [user],
[pass], and [db]. However, no examples are given and no format syntax
is provided. So, it leaves the user guessing. I'm sure that database
URIs are probably standard, and dbmail adheres to this standard, but
it's not stated. I just followed the example in
dbmail-3.2.2/jenkins/Makefile.

A IMAP behavior change from default, login_disabled=no to yes, is not
discussed at all in UPGRADING.

Lastly, the UPGRADING file contains unnecessary information noise. As it
is the user has to read the entire UPGRADING document and determine
which parts apply to their upgrade path. Since this is the 3.2.2
tarball there is no need to explain the upgrade path to 3.0 as long as
you include the full 2.2-to-3.2 path in the explanation. Nobody is
downloading the 3.2.2 tarball in order to perform a 2.2-to-3.0 upgrade.
That information is only relevant so that those upgrading from 2.2 can
try to discern what they need to do. It would be clearer if the
UPGRADING document did not expect the reader to decipher the noise from
the information and merely explain what users of all previous versions
of dbmail would need to do to upgrade and maintain the same functional
behavior.

Thanks,

Lee.

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
Re: upgrade to 3.2.1 [ In reply to ]
Hi,

good that you managed to upgrade!

About the documentation, I'm pretty sure that Paul excepts every patch
that makes the documentation more clear and better readable for all.

Now you have fresh knowledge of the upgrade process, so it would be great
if you write a new UPGRADING text file and share it with us.

thx

Harald


Am .01.2015, 07:52 Uhr, schrieb Lee Howard <faxguy@howardsilvan.com>:

> So after weeks of part-time work resolving dependency issues in the
> upgrade (primarily with GMime and Glib, but libevent was also a minor
> issue) this evening I upgraded from 3.0.2 to 3.2.2.
>
> I did make a backup of the database, but the schema auto-migration
> appears to have worked, things are operational, and I do not notice any
> ill effects with the database at this point.
>
> (I'm hoping that the efforts of this upgrade result in no more
> situations where clients cannot connect to dbmail-imapd and dbmail-pop3d
> services. Whether the problem was in dbmail or in GMime or something
> else, I don't know. I didn't have any problems after upgrading only
> GMime, but I didn't let dbmail-3.0.2 run long-enough with GMime-2.6.20
> to say. Normally I would see one problem every two weeks or so, but
> lately it was more-frequent: like once per-week. I only finished the
> GMime upgrade on Thursday.)
>
> I quickly hit-upon the dbmail-imapd segfault bug fixed here:
>
> https://github.com/pjstevns/dbmail/commit/edd6179d638d4257d0a669de582f8770370a7364
>
> So, I applied that patch, and it seems to have resolved the crashing
> problem.
>
> Upgrade documentation is a concern for me, though...
>
> The UPGRADING document and the sample dbmail.conf file explain that
> [dburi] has deprecated [driver], [host], [sqlport], [sqlsocket], [user],
> [pass], and [db]. However, no examples are given and no format syntax
> is provided. So, it leaves the user guessing. I'm sure that database
> URIs are probably standard, and dbmail adheres to this standard, but
> it's not stated. I just followed the example in
> dbmail-3.2.2/jenkins/Makefile.
>
> A IMAP behavior change from default, login_disabled=no to yes, is not
> discussed at all in UPGRADING.
>
> Lastly, the UPGRADING file contains unnecessary information noise. As it
> is the user has to read the entire UPGRADING document and determine
> which parts apply to their upgrade path. Since this is the 3.2.2
> tarball there is no need to explain the upgrade path to 3.0 as long as
> you include the full 2.2-to-3.2 path in the explanation. Nobody is
> downloading the 3.2.2 tarball in order to perform a 2.2-to-3.0 upgrade..
> That information is only relevant so that those upgrading from 2.2 can
> try to discern what they need to do. It would be clearer if the
> UPGRADING document did not expect the reader to decipher the noise from
> the information and merely explain what users of all previous versions
> of dbmail would need to do to upgrade and maintain the same functional
> behavior.
>
> Thanks,
>
> Lee.
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev


--
Harald Leithner

ITronic
Wiedner Hauptstraße 120/5.1, 1050 Wien, Austria
Tel: +43-1-545 0 604
Fax: +43-1-786 23 88 26
Mobil: +43-699-123 78 4 78
Mail: leithner@itronic.at | itronic.at
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
Re: upgrade to 3.2.1 [ In reply to ]
Attached is a revision of UPGRADING that would have been clearer for me.

I'm not terribly fond of the "TRACE" section and the "Server Changes"
section, as I think that they could be more-concise simply with a
reference to other documentation (namely the dbmail.conf "man" page),
but since they weren't a problem for me I've left them be. For the
most-part I feel that an UPGRADING document is there to highlight the
changes between this version and any previous version that may prove to
be problematic. I don't think that the details need to be documented
there as long as it is documented elsewhere.

Thanks,

Lee.


On 01/12/2015 02:55 AM, Harald Leithner wrote:
> Hi,
>
> good that you managed to upgrade!
>
> About the documentation, I'm pretty sure that Paul excepts every patch
> that makes the documentation more clear and better readable for all.
>
> Now you have fresh knowledge of the upgrade process, so it would be
> great if you write a new UPGRADING text file and share it with us.
>
> thx
>
> Harald
>
>
> Am .01.2015, 07:52 Uhr, schrieb Lee Howard <faxguy@howardsilvan.com>:
>
>> So after weeks of part-time work resolving dependency issues in the
>> upgrade (primarily with GMime and Glib, but libevent was also a minor
>> issue) this evening I upgraded from 3.0.2 to 3.2.2.
>>
>> I did make a backup of the database, but the schema auto-migration
>> appears to have worked, things are operational, and I do not notice
>> any ill effects with the database at this point.
>>
>> (I'm hoping that the efforts of this upgrade result in no more
>> situations where clients cannot connect to dbmail-imapd and
>> dbmail-pop3d services. Whether the problem was in dbmail or in GMime
>> or something else, I don't know. I didn't have any problems after
>> upgrading only GMime, but I didn't let dbmail-3.0.2 run long-enough
>> with GMime-2.6.20 to say. Normally I would see one problem every two
>> weeks or so, but lately it was more-frequent: like once per-week. I
>> only finished the GMime upgrade on Thursday.)
>>
>> I quickly hit-upon the dbmail-imapd segfault bug fixed here:
>>
>> https://github.com/pjstevns/dbmail/commit/edd6179d638d4257d0a669de582f8770370a7364
>>
>>
>> So, I applied that patch, and it seems to have resolved the crashing
>> problem.
>>
>> Upgrade documentation is a concern for me, though...
>>
>> The UPGRADING document and the sample dbmail.conf file explain that
>> [dburi] has deprecated [driver], [host], [sqlport], [sqlsocket],
>> [user], [pass], and [db]. However, no examples are given and no
>> format syntax is provided. So, it leaves the user guessing. I'm
>> sure that database URIs are probably standard, and dbmail adheres to
>> this standard, but it's not stated. I just followed the example in
>> dbmail-3.2.2/jenkins/Makefile.
>>
>> A IMAP behavior change from default, login_disabled=no to yes, is not
>> discussed at all in UPGRADING.
>>
>> Lastly, the UPGRADING file contains unnecessary information noise. As
>> it is the user has to read the entire UPGRADING document and
>> determine which parts apply to their upgrade path. Since this is the
>> 3.2.2 tarball there is no need to explain the upgrade path to 3.0 as
>> long as you include the full 2.2-to-3.2 path in the explanation.
>> Nobody is downloading the 3.2.2 tarball in order to perform a
>> 2.2-to-3.0 upgrade.. That information is only relevant so that those
>> upgrading from 2.2 can try to discern what they need to do. It would
>> be clearer if the UPGRADING document did not expect the reader to
>> decipher the noise from the information and merely explain what users
>> of all previous versions of dbmail would need to do to upgrade and
>> maintain the same functional behavior.
>>
>> Thanks,
>>
>> Lee.
>>
>> _______________________________________________
>> Dbmail-dev mailing list
>> Dbmail-dev@dbmail.org
>> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
>
>
Re: upgrade to 3.2.1 [ In reply to ]
Hi,

thanks for the updated upgrading.txt, I have some notices. You remove a
part auf Upgrading DBMail from 2.2 to 3.0 and 3.0 to 3.1.

Maybe it would be a good idea to create some footnote about these versions.

because if you like to upgrade from 2.2 you will loose the information for
the sql upgrade files that are needed until dbmail 3.2

thx for your work.

Harald

Am .01.2015, 20:26 Uhr, schrieb Lee Howard <faxguy@howardsilvan.com>:

> Attached is a revision of UPGRADING that would have been clearer for me.
>
> I'm not terribly fond of the "TRACE" section and the "Server Changes"
> section, as I think that they could be more-concise simply with a
> reference to other documentation (namely the dbmail.conf "man" page),
> but since they weren't a problem for me I've left them be. For the
> most-part I feel that an UPGRADING document is there to highlight the
> changes between this version and any previous version that may prove to
> be problematic. I don't think that the details need to be documented
> there as long as it is documented elsewhere.
>
> Thanks,
>
> Lee.
>
>
> On 01/12/2015 02:55 AM, Harald Leithner wrote:
>> Hi,
>>
>> good that you managed to upgrade!
>>
>> About the documentation, I'm pretty sure that Paul excepts every patch
>> that makes the documentation more clear and better readable for all.
>>
>> Now you have fresh knowledge of the upgrade process, so it would be
>> great if you write a new UPGRADING text file and share it with us.
>>
>> thx
>>
>> Harald
>>
>>
>> Am .01.2015, 07:52 Uhr, schrieb Lee Howard <faxguy@howardsilvan.com>:
>>
>>> So after weeks of part-time work resolving dependency issues in the
>>> upgrade (primarily with GMime and Glib, but libevent was also a minor
>>> issue) this evening I upgraded from 3.0.2 to 3.2.2.
>>>
>>> I did make a backup of the database, but the schema auto-migration
>>> appears to have worked, things are operational, and I do not notice
>>> any ill effects with the database at this point.
>>>
>>> (I'm hoping that the efforts of this upgrade result in no more
>>> situations where clients cannot connect to dbmail-imapd and
>>> dbmail-pop3d services. Whether the problem was in dbmail or in GMime
>>> or something else, I don't know. I didn't have any problems after
>>> upgrading only GMime, but I didn't let dbmail-3.0.2 run long-enough
>>> with GMime-2.6.20 to say. Normally I would see one problem every two
>>> weeks or so, but lately it was more-frequent: like once per-week. I
>>> only finished the GMime upgrade on Thursday.)
>>>
>>> I quickly hit-upon the dbmail-imapd segfault bug fixed here:
>>>
>>> https://github.com/pjstevns/dbmail/commit/edd6179d638d4257d0a669de582f8770370a7364
>>>
>>>
>>> So, I applied that patch, and it seems to have resolved the crashing
>>> problem.
>>>
>>> Upgrade documentation is a concern for me, though...
>>>
>>> The UPGRADING document and the sample dbmail.conf file explain that
>>> [dburi] has deprecated [driver], [host], [sqlport], [sqlsocket],
>>> [user], [pass], and [db]. However, no examples are given and no
>>> format syntax is provided. So, it leaves the user guessing. I'm
>>> sure that database URIs are probably standard, and dbmail adheres to
>>> this standard, but it's not stated. I just followed the example in
>>> dbmail-3.2.2/jenkins/Makefile.
>>>
>>> A IMAP behavior change from default, login_disabled=no to yes, is not
>>> discussed at all in UPGRADING.
>>>
>>> Lastly, the UPGRADING file contains unnecessary information noise. As
>>> it is the user has to read the entire UPGRADING document and
>>> determine which parts apply to their upgrade path. Since this is the
>>> 3.2.2 tarball there is no need to explain the upgrade path to 3.0 as
>>> long as you include the full 2.2-to-3.2 path in the explanation.
>>> Nobody is downloading the 3.2.2 tarball in order to perform a
>>> 2.2-to-3.0 upgrade.. That information is only relevant so that those
>>> upgrading from 2.2 can try to discern what they need to do. It would
>>> be clearer if the UPGRADING document did not expect the reader to
>>> decipher the noise from the information and merely explain what users
>>> of all previous versions of dbmail would need to do to upgrade and
>>> maintain the same functional behavior.
>>>
>>> Thanks,
>>>
>>> Lee.
>>>
>>> _______________________________________________
>>> Dbmail-dev mailing list
>>> Dbmail-dev@dbmail.org
>>> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
>>
>>
>


--
Harald Leithner

ITronic
Wiedner Hauptstraße 120/5.1, 1050 Wien, Austria
Tel: +43-1-545 0 604
Fax: +43-1-786 23 88 26
Mobil: +43-699-123 78 4 78
Mail: leithner@itronic.at | itronic.at
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev