-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
version bump for offlineimap3 #10
Comments
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. |
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. |
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. |
@pabs3 start reading from here: |
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:
Regards, |
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. |
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.
|
@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? |
@thekix |
Thanks, I agree with you. So, in the same way, unless anyone else has some specific concern with that, I will hold the Thanks a lot for your comments. |
I agree that the Debian package name should be offlineimap, even if the
package contains offlineimap3.
…--
bye,
pabs
https://bonedaddy.net/pabs3/
|
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. 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. |
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). |
Please, notice that I say that offlineimap3 is a fork of offlineimap because it's a fact. |
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. |
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/
|
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.
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? |
It is now in the NEW queue for |
Thank you very much @sudipm-mukherjee ! |
Thanks a lot @sudipm-mukherjee ! Please, any bug in Debian, open it as issue in github. We will try to solve it ASAP |
Hi @thekix @nicolas33 |
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! |
@pabs3 your thoughts please.. |
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, |
@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 ? |
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 |
Yes, of course. I will try to help you. These days I am so busy, sorry about delays. |
I hope that @nicolas33 is okay |
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. |
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? |
@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. |
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/
|
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. 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. |
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.
|
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. |
Congratulations on the family growing part. :) |
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. 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. |
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).
|
Done. Give a small kick to offlineimap3. ;-) |
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. |
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 :-) |
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 |
What is the current plan for a new release? |
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, |
Hi, what should I change? Which files? Comments are welcome! About the init.py file:
I will change the kix |
Version 8.0.0 is up! Thanks for your contributions!! Best regards, |
@thekix congratulations on the first release of offlineimap3. |
Dear @sudipm-mukherjee I think is solved. Sorry about that :-) Is now ok? Best regards, |
Thanks. $ git describe |
Congratulation! |
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
The text was updated successfully, but these errors were encountered: