version bump for offlineimap3 about offlineimap3 HOT 51 CLOSED

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.

from offlineimap3.

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. :)

from offlineimap3.

from offlineimap3.

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 :-)

from offlineimap3.

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.

from offlineimap3.

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?

from offlineimap3.

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

from offlineimap3.

Version 8.0.0 is up!

Thanks for your contributions!!

Best regards,
kix

from offlineimap3.

@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.

from offlineimap3.

Thanks.

$ git describe
v8.0.0-1-ge64c254

from offlineimap3.

Version 8.0.0 is up!

Thanks for your contributions!!

Best regards, kix

Congratulation!

from offlineimap3.

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.

from offlineimap3.

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.

from offlineimap3.

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.

from offlineimap3.

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

from offlineimap3.

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

from offlineimap3.

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 ?

from offlineimap3.

from offlineimap3.

@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?

from offlineimap3.

@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.

from offlineimap3.

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.

from offlineimap3.

from offlineimap3.

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.

from offlineimap3.

@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. ,-)

from offlineimap3.

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

from offlineimap3.

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.

from offlineimap3.

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?

from offlineimap3.

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.

from offlineimap3.

Thank you very much @sudipm-mukherjee !

from offlineimap3.

Thanks a lot @sudipm-mukherjee !

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

from offlineimap3.

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.

from offlineimap3.

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

from offlineimap3.

• We are very near the Debian Bullseye freeze now. Now that #30 and also #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..

from offlineimap3.

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

from offlineimap3.

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.

from offlineimap3.

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 ?

from offlineimap3.

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

from offlineimap3.

I hope that @nicolas33 is okay

from offlineimap3.

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.

from offlineimap3.

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?

from offlineimap3.

@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.

from offlineimap3.

from offlineimap3.

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.

from offlineimap3.

from offlineimap3.

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.

from offlineimap3.

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.

from offlineimap3.

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:

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

from offlineimap3.

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. ;-)

from offlineimap3.

@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.

from offlineimap3.

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__ = "[email protected]"
__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"

I will change the __version__ = "7.3.0" to __version__ = "8.0.0" and the Copyright to Copyright 2002-2021 John Goerzen & contributors. @jgoerzen is it ok for you?

kix

from offlineimap3.

Dear @sudipm-mukherjee

I think is solved. Sorry about that :-)

Is now ok?

Best regards,
kix

from offlineimap3.