version bump for offlineimap3 #10

sudipm-mukherjee · 2020-10-13T20:46:39Z

Hi,
I am planning to package offlineimap3 for Debian (https://bugs.debian.org/970623) and we already have offlineimap3 v7.3.3 in Debian. offlineimap3 has a version of v7.3.0 so that will be a problem, if I update offlineimap package with this. Is there any plan to bump the version to something like v7.4.0-rc1 ?

--
Regards
Sudip

nicolas33 · 2020-10-13T21:41:39Z

I could not find the offlineimap3 in debian so I think there is no package about offlineimap3, actually.

Offlineimap3 is a fork of offlineimap for py3. Both should be considered unrelated when packaging. So, there should be no versionning issue.

Notice that there is no release in offlineimap3, yet. All the current versions/tags in the project is legacy history from offlineimap and should be ignored when packaging offlineimap3. IOW, you should wait for the first official release of offlineimap3.

Is there a deadline about the deletion of offlineimap in debian? If so, we should be aware of this so the maintainer can check if a release is possible before in order to help the transition for the users.

sudipm-mukherjee · 2020-10-13T21:57:11Z

offlineimap3 is not in Debian yet, and I was hoping to update offlineimap to offlineimap3. But if they are to be considered unrelated then I will start the process of adding a new package to Debian.
The freeze dates for Debian Bullseye has already been announced (https://release.debian.org/bullseye/freeze_policy.html), no new package will be accepted from 2021-02-12 and since the review of new packages takes time so I guess the latest target for a release can be first week of December, otherwise we will have the risk of missing offlineimap/offlineimap3 in Debian Bullseye release.

pabs3 · 2020-10-19T23:26:51Z

What is the reason to use a different name for the package? offlineimap3 seems to use the same configuration file and seems to be compatible with the on-disk formats of offlineimap, so changing the package name is just going to be disruptive to existing users. If the package gets renamed they probably won't notice and will continue using the old unsupported offlineimap after the Debian release.

PS: I really don't understand the reason for the fork and I really hope this repo can be merged back into the offlineimap repo.

PPS: please put offlineimap3 in Debian experimental before the next offlineimap3 release, so Debian folks can try it out early.

ff2000 · 2020-10-20T04:38:32Z

@pabs3 start reading from here:
OfflineIMAP/offlineimap#670 (comment)

thekix · 2020-10-20T08:10:00Z

Hello,

I have some things to add. I am using Debian. The offlineimap package was using python2 and I only move it to pyhton3. That was my only target, update the software. The repo name is different because the thread pointed by @ff2000

I have some doubts:

We need have a name for the software: offlineimap or offlineimap3. This name is used in the source (README,...)
Probably both offlineimap versions, python2 and python3, will continue for some time. Perhaps we should use the same name in the distros but different in the github repo. Python2 will be removed in most of the distros.
I proposed update the README (like remove "Project status and future") and other files in the offlineimap3 repo.

Regards,
kix

sudipm-mukherjee · 2020-10-20T08:25:11Z

I think (as a Debian user and an offlineimap user) the package name in Debian should remain same as offlineimap. The github source name will be different as it is now. The next Debian Bullseye release will not have the offlineimap (python2 version) so there should not be any conflict if we package offlineimap3 as offlineimap for Debian Bullseye.
Thoughts? @pabs3 ?

pabs3 · 2020-10-20T08:27:41Z

I agree, the Debian offlineimap package in Debian bullseye should be offlineimap3 (or offlineimap with the offlineimap3 changes merged) rather than the Python 2 only offlineimap.

thekix · 2020-10-20T12:00:17Z

@sudipm-mukherjee @pabs3 I am not sure about your posts. When I read the @sudipm-mukherjee post, my idea is the package name in Debian should be "offlineimap" and the repo name should be offlineimap3. But in the @pabs3 post, I understand the package name in Debian should be"offlineimap3". I am wrong?

@nicolas33 do you have plans to merge the offlineimap3 in offlineimap (python2). We should think about different software? In the project name, documentation,... I should continue using offlineimap or change the name to offlineimap3?

sudipm-mukherjee · 2020-10-20T12:10:13Z

@thekix
@pabs3 agreed with #10 (comment).
So unless you or @nicolas33 or anyone else has some specific concern with that I will upload offlineimap3 as offlineimap in experimental https://wiki.debian.org/DebianExperimental. And as I mentioned in my post, since 'offlineimap' has already been removed so there wont be any conflict.

thekix · 2020-10-20T13:14:07Z

Thanks,

I agree with you. So, in the same way, unless anyone else has some specific concern with that, I will hold the offlineimap name in the documentation. About the version, I will update it after change some files (README,...) I hope do it soon.

Thanks a lot for your comments.
Best regards,
Rodolfo.

pabs3 · 2020-10-20T15:34:39Z

I agree that the Debian package name should be offlineimap, even if the package contains offlineimap3.

…

-- bye, pabs https://bonedaddy.net/pabs3/

nicolas33 · 2020-10-20T23:46:46Z

offlineimap3 is definetely a fork.

Migrating to py3 requires deep changes and we won't support both py2 and py3 in offlineimap. So, merging changes back is not contemplated. We might cherry-pick some little changes but that's all.
We don't know when offlineimap3 will be ready and we still need a working offlineimap/py2 project.

Debian is free to package the softwares how they want it but that's wrong to package offlineimap3 as offlineimap, IMHO. Users wanting both offlineimap (e.g. for production use, from manual install) and offlineimap3 (e.g. for testing, from the debian package) will have name and import conflicts.
Also, the version numbers will get mixed and make things sightly complicated for the users.
People will get confused.

nicolas33 · 2020-10-21T00:04:58Z

@nicolas33 do you have plans to merge the offlineimap3 in offlineimap (python2). We should think about different software? In the project name, documentation,... I should continue using offlineimap or change the name to offlineimap3?

No, I don't have plans to merge offlineimap3 back in offlineimap. I'm not pretending this will never happen, though. Once offlineimap is dead there will be free space about the naming (and the OfflineIMAP/offlineimap github repository).

About the doc, the website, etc, I think that you might like to keep the 'offlineimap' name if you want to be able to easily supersede offlineimap/py2 when time will come. Feel free to make deeper naming changes or not.

I'm expecting to announce that offlineimap/py2 is dead, one day. Not any time soon, though. At least, not before offlineimap3 is ready and that we've discussed about this in depth. The time of this discussion will come but we're not here and both projects will continue to diverge until then (they've already diverged, BTW).
AFAICT, offlineimap3 still doesn't even have its first official release, yet. ,-)

nicolas33 · 2020-10-21T00:14:28Z

Please, notice that I say that offlineimap3 is a fork of offlineimap because it's a fact.

nicolas33 · 2020-10-21T00:21:55Z

offlineimap3 seems to use the same configuration file and seems to be compatible with the on-disk formats of offlineimap

There's no guarantee that this will stay true. offlineimap3 has just started. We don't know what could happen (for both projects).

Think about the cache, for example. If one needs to move to UTF names and not the other, both projects would become incompatible.

pabs3 · 2020-10-21T00:54:39Z

Is the Python 2 offlineimap continuing to be developed in a divergent way? Personally, I would say after the first release of offlineimap3, declare offlineimap3 as the successor of offlineimap and end all development of offlineimap.

…

-- bye, pabs https://bonedaddy.net/pabs3/

nicolas33 · 2020-10-21T19:46:05Z

Is the Python 2 offlineimap continuing to be developed in a divergent way?

Yes. We don't have the choice, here. In oder to not diverge we would have to stop the development of offlineimap/py2.

Please, don't get me wrong. I'm an high offlineimap3 enthousiast. I'd be delighted that this project is a success, more than offlineimap/py2.

Personally, I would say after the first release of offlineimap3, declare offlineimap3 as the successor of offlineimap and end all development of offlineimap.

I won't stop the development of offlineimap/py2 with the first offlineimap3 release because emails are critical for some users. We do have a wide range of end-users with high-level expectations and/or production constraints. We need a working and production ready offlineimap3 before we can stop offlineimap/py2. What if offlineimap3 fails at some point to reach the users expectations or never become production ready?

sudipm-mukherjee · 2020-10-26T22:22:51Z

It is now in the NEW queue for experimental as a new separate package and can be seen at https://ftp-master.debian.org/new/offlineimap3_0.0~git20201025.c850e74+dfsg-1.html. The version is temporary and will be fixed after the first official release of offlineimap3.

nicolas33 · 2020-10-26T22:34:20Z

Thank you very much @sudipm-mukherjee !

thekix · 2020-10-27T08:57:28Z

Thanks a lot @sudipm-mukherjee !

Please, any bug in Debian, open it as issue in github. We will try to solve it ASAP

sudipm-mukherjee · 2020-12-23T20:26:02Z

Hi @thekix @nicolas33
Any thoughts about an official release? It has been in Debian experimental for quite some time and I really need to upload to unstable if we want it to be in Debian Bullseye release.

thekix · 2020-12-24T16:57:14Z

Hi @sudipm-mukherjee

I am using offlineimap and for me is ok. But we have some issues, like #30 that could impact to other users. The problem related to #30 is about imaplib2, not about offlineimap. I am thinking about it, probably we need rewrite some parts of imaplib2 for python3 before have offlineimap stable.

What do you think @nicolas33 ?

Merry Christmas!
kix

sudipm-mukherjee · 2021-01-12T15:54:47Z

We are very near the Debian Bullseye freeze now. Now that Fails to establish IMAP connection across preauth tunnel #30 and also foldersort broken: '<' not supported between instances of 'K' and 'K' #33 is fixed, any new thoughts about a release?
If there is no official release, then how confident are we to include what we have in Bullseye?

@pabs3 your thoughts please..

thekix · 2021-01-12T16:12:06Z

Hi,

IMO, we can create a first release.

@nicolas33 what do you think? What should we do to create it? Could you check the issue #31?

Regards,
kix

sudipm-mukherjee · 2021-01-14T20:38:24Z

Thanks @thekix.
Since you think you can create the first release I assume you consider the HEAD (00d395b) is stable enough. I think I will then upload it to Debian unstable and remove from experimental and wait for your release.

sudipm-mukherjee · 2021-01-17T22:24:41Z

Debian is free to package the softwares how they want it but that's wrong to package offlineimap3 as offlineimap, IMHO. Users wanting both offlineimap (e.g. for production use, from manual install) and offlineimap3 (e.g. for testing, from the debian package) will have name and import conflicts.
Also, the version numbers will get mixed and make things sightly complicated for the users.
People will get confused.

@nicolas33 Do you still have this same opinion ? As offlineimap is now removed from Debian Bullseye release I now have the option to create a transitional package to migrate offlineimap users to offlineimap3 or have offlineimap3 as a completely new package without any relation to offlineimap. As maintainer of offlineimap which one will you prefer ?

sudipm-mukherjee · 2021-01-23T22:59:08Z

In absence of any reply from @nicolas33 and since the Debian maintainer of offlineimap is ok with the idea of transitional package, I am going ahead with that. Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937831#68
I hope @thekix will be there to support me in the bug reports we might get after the transition.

thekix · 2021-01-24T01:17:06Z

Yes, of course. I will try to help you. These days I am so busy, sorry about delays.

thekix · 2021-01-24T01:21:08Z

I hope that @nicolas33 is okay

sudipm-mukherjee · 2021-01-24T22:27:28Z

Thanks @thekix. I would have preferred to wait for reply from @nicolas33 but the freeze is very near now and I have uploaded the transitional package.

uqs · 2021-05-02T09:23:33Z

Hey folks, I'm from FreeBSD and we could also really use a release tag for offlineimap3 to package this up in ports as the successor to offlineimap (because that has been removed and will never come back), so there's no naming conflict and the users don't even have the choice of installing both versions at the same time.

Is it correct that the config is compatible? So I should be able to run offlineimap and offlineimap3 with the same user config and things should mostly just work, yes?

sudipm-mukherjee · 2021-05-02T22:06:45Z

@uqs The config is mostly compatible. From Debian I have not yet seen any report of problem with config. Most of the problems till now had been due to python2 and python3 incompatibilities. Most of them are in the issues.

pabs3 · 2021-05-03T01:10:22Z

Earlier in the thread it was mentioned that there is no compatibility guarantee and that development of both repos will continue in parallel, which lead Debian to package it as offlineimap3 rather than offlineimap, although a transitional offlineimap package did get added.

…

-- bye, pabs https://bonedaddy.net/pabs3/

nicolas33 · 2021-07-28T23:00:33Z

I'm so sorry for this very long delay. I'm fine, thanks! My family is growing, I've moved, lockdowns, etc, etc.

I think you all did a very good job, BTW. I'm delighted to see all of this happen.

@thekix is managing offlineimap3 like a boss. I'll see what I can do to grant him all the rights he's currently lacking for whatever he is willing to take (travisCI, twitter, github, mailing list, websites, etc). It's time.

I still think that offlineimap3 and offlineimap should be seperated projects. It's a good thing to have offlineimap not being packaged anymore in the distributions (how a py2 project could pretend this BTW?). It's way better to leave it off.
However, if users hit issues or want to keep running offlineimap from the sources (not something hard to do) it should be clear where to find offlineimap and not be confused with the offlineimap3 project. Emails are often considered critical by our users. We should avoid the pain for them. Above this, I don't have strong opinions.

The final decision is yours. The offlineimap3 project should now take precedence over anything related to offlineimap. Don't let the legacy python2 project to harm in any way.

Hence, I consider that decisions related to both offlineimap3 and offlineimap/py2 taken by @thekix are directions we should take, including me.

ildar · 2021-07-29T04:02:38Z

On Thu, Jul 29, 2021 at 5:00 AM Nicolas Sebrecht wrote: It's a good thing to have offlineimap not being packaged anymore in the distributions (how a py2 project could pretend this BTW?). It's way better to leave it off. py3 deps still have some critical issue(s) that render offlineimap3

useless.

thekix · 2021-07-31T16:43:52Z

Hi @nicolas33 !

I am happy that you are fine :-) This is the most important!

Thanks a lot for your words. You were working a lot for offlineimap, for a long time, and you have a LOT of knowledge. IMO, all of us, and of course you, should take the decisions together.

sudipm-mukherjee · 2021-07-31T20:06:09Z

I'm so sorry for this very long delay. I'm fine, thanks! My family is growing, I've moved, lockdowns, etc, etc.

Congratulations on the family growing part. :)

nicolas33 · 2021-07-31T22:53:08Z

Thanks a lot for your words. You were working a lot for offlineimap, for a long time, and you have a LOT of knowledge. IMO, all of us, and of course you, should take the decisions together.

I don't know the current state of offlineimap3. The transition is all about the users. As soon as you think it's working well enough, we're fine with the move.
AFAICT the last release is still 7.3.3 coming from the offlineimap history. I'd suggest to release a new version. Whatever the current stage it's always good to have pointers to versions. Also, it's impossible to have everything working on the first release. And nearly impossible on the next release, too. The most important is not what's in the release, it's the communication to the distribution maintainers and the users.
If ever need be, it's welcome to release something marked release candidate or 'testing release'. As long as the current stage is explained in the release notes.

Whatever is your choice to declare it stable or not, you have my full support. And yes, I recommend to release something.

Another topic is when should we redirect people from offlineimap to offlineimap3 in the README. I wonder we should do this now. I'll update the README of offlineimap as soon as you think it's time.

nicolas33 · 2021-07-31T23:02:06Z

As a side note, if users are hitting issues with offlineimap3 we are fine as long as they can re-install offlineimap (including maually) to get their emails (that's all my point about not confusing the users with the package names).
If their configuration gets broken we just have to explain them what to do:

open a new issue on the offlineimap3 project
re-install offlineimap from the sources for the time to fix the issue
help to close the issue

nicolas33 · 2021-08-02T23:28:28Z

Another topic is when should we redirect people from offlineimap to offlineimap3 in the README. I wonder we should do this now. I'll update the README of offlineimap as soon as you think it's time.

Done. Give a small kick to offlineimap3. ;-)

nicolas33 · 2021-08-13T18:00:20Z

@thekix

I've released offlineimap/py2 v7.3.4 at the beginning of the month. Other bug-fixes releases might come.

I think you should start with either v7.4.0 or v8.0.0. This way we can reserve the v7.3.x versions to offlineimap/py2 in order to avoid overlapping versions.

thekix · 2021-08-13T19:37:52Z

Hi @nicolas33

IMO, I think is better change to 8.0.0, because there are many changes with Python3, and we have more versions for Offllinemap (py2). Moving to 8.0.0 solves a problem about version number in Debian too (cc: @sudipm-mukherjee )

But is only my opinion, perhaps more people could show different points of view :-)

sudipm-mukherjee · 2021-08-13T20:44:51Z

8.0.0 sounds good. But in Debian I have worked around the versioning problem in the absence of an official release by using the git SHA in version. The version going to Debian Bullseye is 0.0~git20210225.1e7ef9e+dfsg-4. So, we can jump to any version more than 0.0.

brandsimon · 2021-08-30T13:27:22Z

What is the current plan for a new release?
Also archlinux wants a release to be packaged: https://bugs.archlinux.org/task/71933?project=5&string=offlineimap
Is there a list with todos I can help with?

thekix · 2021-10-12T13:50:55Z

Hi,

sorry about the delay.

After some tests and after remove the bug about self-signed certificates, I will create the new version soon. Please, wait for the issue #88 (max. wait the next Sunday).

I will use the version number 8.0.0

Best regards,
kix

thekix · 2021-10-12T16:34:10Z

Hi,

what should I change? Which files? Comments are welcome!

About the init.py file:

__productname__ = 'OfflineIMAP'
# Expecting trailing "-rcN" or "" for stable releases.
__version__ = "7.3.0"
__copyright__ = "Copyright 2002-2019 John Goerzen & contributors"
__author__ = "John Goerzen"
__author_email__ = "offlineimap-project@lists.alioth.debian.org"
__description__ = "Disconnected Universal IMAP Mail Synchronization/Reader Support"
__license__ = "Licensed under the GNU GPL v2 or any later version (with an OpenSSL exception)"
__bigcopyright__ = """%(__productname__)s %(__version__)s
  %(__license__)s""" % locals()
__homepage__ = "http://www.offlineimap.org"

kix

thekix · 2021-10-18T13:04:06Z

Version 8.0.0 is up!

Thanks for your contributions!!

Best regards,
kix

sudipm-mukherjee · 2021-10-18T16:43:35Z

@thekix congratulations on the first release of offlineimap3.
But there seems to be some problem.
"git describe" gives me "v7.3.0-402-ge64c254".
"git describe --tags" gives me "v8.0.0-1-ge64c254".
You might need to use annotated tags for "git describe" to give the correct information.
And also, you have merged the tag via a PR and so I am getting "v8.0.0-1-ge64c254", which is ok if you prefer to do releases via PR.

thekix · 2021-10-18T17:21:29Z

Dear @sudipm-mukherjee

I think is solved. Sorry about that :-)

Is now ok?

Best regards,
kix

sudipm-mukherjee · 2021-10-18T17:25:49Z

Thanks.

$ git describe
v8.0.0-1-ge64c254

nicolas33 · 2021-10-18T21:31:33Z

Version 8.0.0 is up!

Thanks for your contributions!!

Best regards, kix

Congratulation!

thekix mentioned this issue Oct 18, 2021

v8.0.0 #94

Merged

3 tasks

thekix closed this as completed Oct 18, 2021

version bump for offlineimap3 #10

version bump for offlineimap3 #10

Comments

sudipm-mukherjee commented Oct 13, 2020

nicolas33 commented Oct 13, 2020

sudipm-mukherjee commented Oct 13, 2020

pabs3 commented Oct 19, 2020

ff2000 commented Oct 20, 2020

thekix commented Oct 20, 2020

sudipm-mukherjee commented Oct 20, 2020

pabs3 commented Oct 20, 2020 via email

thekix commented Oct 20, 2020

sudipm-mukherjee commented Oct 20, 2020

thekix commented Oct 20, 2020

pabs3 commented Oct 20, 2020 via email

nicolas33 commented Oct 20, 2020 • edited Loading

nicolas33 commented Oct 21, 2020 • edited Loading

nicolas33 commented Oct 21, 2020

nicolas33 commented Oct 21, 2020 • edited Loading

pabs3 commented Oct 21, 2020 via email

nicolas33 commented Oct 21, 2020

sudipm-mukherjee commented Oct 26, 2020

nicolas33 commented Oct 26, 2020

thekix commented Oct 27, 2020

sudipm-mukherjee commented Dec 23, 2020

thekix commented Dec 24, 2020

sudipm-mukherjee commented Jan 12, 2021

thekix commented Jan 12, 2021

sudipm-mukherjee commented Jan 14, 2021

sudipm-mukherjee commented Jan 17, 2021

sudipm-mukherjee commented Jan 23, 2021

thekix commented Jan 24, 2021

thekix commented Jan 24, 2021

sudipm-mukherjee commented Jan 24, 2021

uqs commented May 2, 2021

sudipm-mukherjee commented May 2, 2021

pabs3 commented May 3, 2021 via email

nicolas33 commented Jul 28, 2021 • edited Loading

ildar commented Jul 29, 2021 via email

thekix commented Jul 31, 2021

sudipm-mukherjee commented Jul 31, 2021

nicolas33 commented Jul 31, 2021 • edited Loading

nicolas33 commented Jul 31, 2021

nicolas33 commented Aug 2, 2021

nicolas33 commented Aug 13, 2021

thekix commented Aug 13, 2021

sudipm-mukherjee commented Aug 13, 2021

brandsimon commented Aug 30, 2021

thekix commented Oct 12, 2021

thekix commented Oct 12, 2021

thekix commented Oct 18, 2021

sudipm-mukherjee commented Oct 18, 2021

thekix commented Oct 18, 2021

sudipm-mukherjee commented Oct 18, 2021

nicolas33 commented Oct 18, 2021

nicolas33 commented Oct 20, 2020 •

edited

Loading

nicolas33 commented Oct 21, 2020 •

edited

Loading

nicolas33 commented Oct 21, 2020 •

edited

Loading

nicolas33 commented Jul 28, 2021 •

edited

Loading

nicolas33 commented Jul 31, 2021 •

edited

Loading