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

Follow roadmap for 2.0 #372

Closed
liZe opened this Issue Apr 4, 2016 · 32 comments

Comments

Projects
None yet
7 participants
@liZe
Member

liZe commented Apr 4, 2016

As defined in #364.

  • Stay simple:
    • Keep only what's needed:
    • Clean the documentation:
      • Mention versions covered by the documentation (#157).
      • Use GitHub to host the website (#310).
      • Create a new design for the website.
    • Write the documentation:
      • Migration guide.
      • Install (#112)
        • What is Radicale.
        • Tutorial.
        • Simple installation.
        • Production-ready installation (#197, #266, #270, #276, #388).
        • Versioning.
      • Use
        • Configuration of clients.
      • Configure
        • What can be configured?
        • Auth and rights. (#538)
        • Storage.
        • Logging.
      • Hack
        • How does Radicale work.
        • Plugins.
        • Debugging.
        • Documentation.
  • Become solid:
    • Use standards:
      • Keep the WSGI interface, use Python HTTP server by default.
      • Use a real iCal parser (icalendar, vobject).
      • Don't rely on slashes (#322).
      • Build a solid calendar discovery (#292).
      • Respect the difference between "files" and "folders" (#366).
      • Remove the calendar creation with GET requests (#240, #248, #252).
      • Define how to create collections (#384).
    • Be thread-safe:
  • Provide needed new features:

@liZe liZe added this to the 2.0 milestone Apr 4, 2016

@liZe liZe self-assigned this Apr 4, 2016

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Apr 7, 2016

Member

I've removed the extra storage, auth and rights modules. Anyone is insterested in testing the new code and config file?

Member

liZe commented Apr 7, 2016

I've removed the extra storage, auth and rights modules. Anyone is insterested in testing the new code and config file?

@untitaker

This comment has been minimized.

Show comment
Hide comment
@untitaker

untitaker Apr 7, 2016

Contributor

Could you keep the refactor out of master until it is finished? Thanks!

Will test soon, but right now I have to deal with the dev version being broken in my CI. :(

Contributor

untitaker commented Apr 7, 2016

Could you keep the refactor out of master until it is finished? Thanks!

Will test soon, but right now I have to deal with the dev version being broken in my CI. :(

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Apr 8, 2016

Member

Could you keep the refactor out of master until it is finished? Thanks!

I won't, sorry :/.

I've had really bad experiences with keeping ongoing development out of master, and good experiences after with big changes in master early:

  • no pull requests on the "old" branch when they're outdated/irrelevent with the "new" one,
  • lots of people understand early that "something is going on",
  • more early testers and early discussions,
  • no "big surprise" when the new branch is merged, with endless discussions on what should have been done after weeks/months of work.

By the way, I've added a 1.1.x branch, and I'm trying to keep master working even with big changes (Travis is watching us!)

Will test soon, but right now I have to deal with the dev version being broken in my CI. :(

Thank you, good luck!

Member

liZe commented Apr 8, 2016

Could you keep the refactor out of master until it is finished? Thanks!

I won't, sorry :/.

I've had really bad experiences with keeping ongoing development out of master, and good experiences after with big changes in master early:

  • no pull requests on the "old" branch when they're outdated/irrelevent with the "new" one,
  • lots of people understand early that "something is going on",
  • more early testers and early discussions,
  • no "big surprise" when the new branch is merged, with endless discussions on what should have been done after weeks/months of work.

By the way, I've added a 1.1.x branch, and I'm trying to keep master working even with big changes (Travis is watching us!)

Will test soon, but right now I have to deal with the dev version being broken in my CI. :(

Thank you, good luck!

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Apr 9, 2016

Member

I've tested the current version (af19377) with Thunderbird, DAVdroid and CalDAV Sync Adapter. Collection discovery seems to work well with and without authentication.

Member

liZe commented Apr 9, 2016

I've tested the current version (af19377) with Thunderbird, DAVdroid and CalDAV Sync Adapter. Collection discovery seems to work well with and without authentication.

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Apr 11, 2016

Member

The Collection API has been changed as proposed in #130.

Member

liZe commented Apr 11, 2016

The Collection API has been changed as proposed in #130.

@untitaker

This comment has been minimized.

Show comment
Hide comment
@untitaker

untitaker Apr 18, 2016

Contributor

BTW I think eventable/vobject#23 should be considered a blocker issue.

Contributor

untitaker commented Apr 18, 2016

BTW I think eventable/vobject#23 should be considered a blocker issue.

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe May 25, 2016

Member

The file locker has been implemented in #402.

I've tested (not for a long time) the current master branch with many clients, including Cadaver, Thunderbird, iOS Calendar, OSX Calendar, and it seems to work well.

Member

liZe commented May 25, 2016

The file locker has been implemented in #402.

I've tested (not for a long time) the current master branch with many clients, including Cadaver, Thunderbird, iOS Calendar, OSX Calendar, and it seems to work well.

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Jul 13, 2016

Member

I've removed freebusy (#34) and sync-collection REPORT (#306) from the roadmap, as they need a lot of time. I'll fix the two last technical tickets (#440 and #327) and realease a new RC soon.

The next step is testing and documentation writing. Anyone interested?

Member

liZe commented Jul 13, 2016

I've removed freebusy (#34) and sync-collection REPORT (#306) from the roadmap, as they need a lot of time. I'll fix the two last technical tickets (#440 and #327) and realease a new RC soon.

The next step is testing and documentation writing. Anyone interested?

@untitaker

This comment has been minimized.

Show comment
Hide comment
@untitaker

untitaker Jul 13, 2016

Contributor

I consider #384 and the previous one I mentioned to be blocker issues.

On 13 July 2016 16:11:42 CEST, Guillaume Ayoub notifications@github.com wrote:

I've removed freebusy (#34) and sync-collection REPORT (#306) from the
roadmap, as they need a lot of time. I'll fix the two last technical
tickets (#440 and #327) and realease a new RC soon.

The next step is testing and documentation writing. Anyone interested?


You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#372 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Contributor

untitaker commented Jul 13, 2016

I consider #384 and the previous one I mentioned to be blocker issues.

On 13 July 2016 16:11:42 CEST, Guillaume Ayoub notifications@github.com wrote:

I've removed freebusy (#34) and sync-collection REPORT (#306) from the
roadmap, as they need a lot of time. I'll fix the two last technical
tickets (#440 and #327) and realease a new RC soon.

The next step is testing and documentation writing. Anyone interested?


You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#372 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Jul 13, 2016

Member

I consider #384 and the previous one I mentioned to be blocker issues.

eventable/vobject#23 has been merged in vobject, so that shouldn't be a problem anymore. #384 is a real problem.

Member

liZe commented Jul 13, 2016

I consider #384 and the previous one I mentioned to be blocker issues.

eventable/vobject#23 has been merged in vobject, so that shouldn't be a problem anymore. #384 is a real problem.

@untitaker

This comment has been minimized.

Show comment
Hide comment
@untitaker

untitaker Jul 13, 2016

Contributor

Sorry, I meant eventable/vobject#33

On 13 July 2016 16:22:55 CEST, Guillaume Ayoub notifications@github.com wrote:

I consider https://github.com/Korea/Radicale/issues/384 and the
previous one I mentioned to be blocker issues.

eventable/vobject#23 has been merged in vobject, so that shouldn't be a
problem anymore. #384 is a real problem.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#372 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Contributor

untitaker commented Jul 13, 2016

Sorry, I meant eventable/vobject#33

On 13 July 2016 16:22:55 CEST, Guillaume Ayoub notifications@github.com wrote:

I consider https://github.com/Korea/Radicale/issues/384 and the
previous one I mentioned to be blocker issues.

eventable/vobject#23 has been merged in vobject, so that shouldn't be a
problem anymore. #384 is a real problem.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#372 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

@untitaker

This comment has been minimized.

Show comment
Hide comment
@untitaker

untitaker Jul 13, 2016

Contributor

Also I would propose waiting for a vobject release and setting the new version as minimal requirement, otherwise I'd imagine that a lot of bugreports will arrive when using older versions.

On 13 July 2016 16:22:55 CEST, Guillaume Ayoub notifications@github.com wrote:

I consider https://github.com/Korea/Radicale/issues/384 and the
previous one I mentioned to be blocker issues.

eventable/vobject#23 has been merged in vobject, so that shouldn't be a
problem anymore. #384 is a real problem.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#372 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Contributor

untitaker commented Jul 13, 2016

Also I would propose waiting for a vobject release and setting the new version as minimal requirement, otherwise I'd imagine that a lot of bugreports will arrive when using older versions.

On 13 July 2016 16:22:55 CEST, Guillaume Ayoub notifications@github.com wrote:

I consider https://github.com/Korea/Radicale/issues/384 and the
previous one I mentioned to be blocker issues.

eventable/vobject#23 has been merged in vobject, so that shouldn't be a
problem anymore. #384 is a real problem.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#372 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Aug 5, 2016

Member

Everything seems to be OK on the technical side now (except from eventable/vobject#33). There's a couple of small features to add and small bugs to check, but nothing like what's been done during the last weeks.

Thank you for the amazing work 👏.

I'll start the documentation during the next days, following what's been defined in this ticket and the open documentation tickets of the milestone.

Member

liZe commented Aug 5, 2016

Everything seems to be OK on the technical side now (except from eventable/vobject#33). There's a couple of small features to add and small bugs to check, but nothing like what's been done during the last weeks.

Thank you for the amazing work 👏.

I'll start the documentation during the next days, following what's been defined in this ticket and the open documentation tickets of the milestone.

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Aug 10, 2016

Member

Here are the first pages of the future website. If anyone is interested…

Member

liZe commented Aug 10, 2016

Here are the first pages of the future website. If anyone is interested…

@untitaker

This comment has been minimized.

Show comment
Hide comment
@untitaker

untitaker Aug 11, 2016

Contributor

The site design is very nice!

I consider "shares through WebDAV" an overstatement since Radicale only supports the set of WebDAV required for CalDAV and CardDAV. In practice I've not been able to mount Radicale collections with davfs. It is possible with owncloud though.

Also I'm not sure what you mean with "warns on concurrent editing" and "secure connections".

On 10 August 2016 18:11:13 CEST, Guillaume Ayoub notifications@github.com wrote:

Here is the first pages of the future
website
. If anyone is interested…


You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#372 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Contributor

untitaker commented Aug 11, 2016

The site design is very nice!

I consider "shares through WebDAV" an overstatement since Radicale only supports the set of WebDAV required for CalDAV and CardDAV. In practice I've not been able to mount Radicale collections with davfs. It is possible with owncloud though.

Also I'm not sure what you mean with "warns on concurrent editing" and "secure connections".

On 10 August 2016 18:11:13 CEST, Guillaume Ayoub notifications@github.com wrote:

Here is the first pages of the future
website
. If anyone is interested…


You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#372 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Aug 11, 2016

Member

The site design is very nice!

😄.

Oh… You'll be impressed when our webdesigners work on that!

I consider "shares through WebDAV" an overstatement since Radicale only supports the set of WebDAV required for CalDAV and CardDAV.

1.x versions were not able at all to talk to WebDAV clients, but 2.x versions will be much better. It's working at least with OwnCloud and Cadaver.

In practice I've not been able to mount Radicale collections with davfs.

I didn't know davfs, it's really cool! I've tried it and… Guess what, it works perfectly! Setting use_locks 0 in /etc/davfs2/davfs2.conf is the only thing I did, and I'm able to copy and rename files and directories, and of course edit files 😉. Really amazing.

Also I'm not sure what you mean with "warns on concurrent editing" and "secure connections".

"Warns on concurrent editing" means that, for clients supporting this feature, Radicale will refuse to edit an item that has been modified since the last time the client downloaded it.

"Secure connections" means that Radicale supports HTTPS, even without a "real" HTTP server.

Member

liZe commented Aug 11, 2016

The site design is very nice!

😄.

Oh… You'll be impressed when our webdesigners work on that!

I consider "shares through WebDAV" an overstatement since Radicale only supports the set of WebDAV required for CalDAV and CardDAV.

1.x versions were not able at all to talk to WebDAV clients, but 2.x versions will be much better. It's working at least with OwnCloud and Cadaver.

In practice I've not been able to mount Radicale collections with davfs.

I didn't know davfs, it's really cool! I've tried it and… Guess what, it works perfectly! Setting use_locks 0 in /etc/davfs2/davfs2.conf is the only thing I did, and I'm able to copy and rename files and directories, and of course edit files 😉. Really amazing.

Also I'm not sure what you mean with "warns on concurrent editing" and "secure connections".

"Warns on concurrent editing" means that, for clients supporting this feature, Radicale will refuse to edit an item that has been modified since the last time the client downloaded it.

"Secure connections" means that Radicale supports HTTPS, even without a "real" HTTP server.

@aminb

This comment has been minimized.

Show comment
Hide comment
@aminb

aminb Sep 6, 2016

Really looking forward to 2.0!

@liZe Any pointers or recommendations for "simple installation" for personal use? I'm about to re-setup my VPS from scratch and would love to use Radicale 2.0 for my calendars and contacts.

aminb commented Sep 6, 2016

Really looking forward to 2.0!

@liZe Any pointers or recommendations for "simple installation" for personal use? I'm about to re-setup my VPS from scratch and would love to use Radicale 2.0 for my calendars and contacts.

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Sep 7, 2016

Member

Any pointers or recommendations for "simple installation" for personal use? I'm about to re-setup my VPS from scratch and would love to use Radicale 2.0 for my calendars and contacts.

Installing from scratch for personal use is really easy. You can follow what's in the future tutorial :

  • install with pip install git+https://github.com/Kozea/Radicale.git:
  • store your configuration in ~/.config/radicale/config,
  • use nohup or something like this.

That's all!

Member

liZe commented Sep 7, 2016

Any pointers or recommendations for "simple installation" for personal use? I'm about to re-setup my VPS from scratch and would love to use Radicale 2.0 for my calendars and contacts.

Installing from scratch for personal use is really easy. You can follow what's in the future tutorial :

  • install with pip install git+https://github.com/Kozea/Radicale.git:
  • store your configuration in ~/.config/radicale/config,
  • use nohup or something like this.

That's all!

@aminb

This comment has been minimized.

Show comment
Hide comment
@aminb

aminb Sep 8, 2016

Ha I see, thanks! I'll try and see if I can run it behind nginx.

aminb commented Sep 8, 2016

Ha I see, thanks! I'll try and see if I can run it behind nginx.

@pbiering

This comment has been minimized.

Show comment
Hide comment
@pbiering

pbiering Sep 14, 2016

Contributor

Dropping Phyton 2.x support and enforcing Phyton 3.x leads to installation problems on Enterprise Linux version 7 (latest RHEL or CentOS).
Biggest issue is that I haven't found a mod_wsgi module for EL7 -> radicale "must" run in standalone mode with Apache in front using ProxyPass
Major issue is missing "python34-vobject", but this is solvable by an adjusted rebuild of SRPM of latest Fedora version.

I can confirm now proper working with "Thunderbird Inverse SoGo Connector", for migration from old multi-filesystem one should perhaps document, that calender "folder" layout changed:

Old:
/user/calendar-1/id-of-entry-1.ics
/user/calendar-1/id-of-entry-2.ics
...
/user/calendar-1.props containing "VCALENDAR"

New:
/user/calendar-1/id-of-entry-1.ics
/user/calendar-1/id-of-entry-2.ics
...
/user/calendar-1/.Radicale.props containing "VCALENDAR"

BTW: in case a manual calendar folder was created on file system but missing .Radicale.props and then using SoGo connector with folder URL leads to a very strange result:
new calendar entries are created as folders, entry contents is a file in that folder having a short hashed name, .Radicale.props is also stored in the folder, directory/file permissions on Unix are 777 and SoGo can't read back the entry (because dot-props for folder is missing):
/user/calendar-with-no-dot-props/id-of-entry-1.ics/shortid
/user/calendar-with-no-dot-props/id-of-entry-1.ics/.Radicale.props
-> somehow not expected, I would suggest rejecting creation of entries in a folder in case this is not explicitly defined in .Radicale.props as VCALENDAR or VADRESSBOOK.

Permissions of 777 are probably the result of umask(0), see #540

Contributor

pbiering commented Sep 14, 2016

Dropping Phyton 2.x support and enforcing Phyton 3.x leads to installation problems on Enterprise Linux version 7 (latest RHEL or CentOS).
Biggest issue is that I haven't found a mod_wsgi module for EL7 -> radicale "must" run in standalone mode with Apache in front using ProxyPass
Major issue is missing "python34-vobject", but this is solvable by an adjusted rebuild of SRPM of latest Fedora version.

I can confirm now proper working with "Thunderbird Inverse SoGo Connector", for migration from old multi-filesystem one should perhaps document, that calender "folder" layout changed:

Old:
/user/calendar-1/id-of-entry-1.ics
/user/calendar-1/id-of-entry-2.ics
...
/user/calendar-1.props containing "VCALENDAR"

New:
/user/calendar-1/id-of-entry-1.ics
/user/calendar-1/id-of-entry-2.ics
...
/user/calendar-1/.Radicale.props containing "VCALENDAR"

BTW: in case a manual calendar folder was created on file system but missing .Radicale.props and then using SoGo connector with folder URL leads to a very strange result:
new calendar entries are created as folders, entry contents is a file in that folder having a short hashed name, .Radicale.props is also stored in the folder, directory/file permissions on Unix are 777 and SoGo can't read back the entry (because dot-props for folder is missing):
/user/calendar-with-no-dot-props/id-of-entry-1.ics/shortid
/user/calendar-with-no-dot-props/id-of-entry-1.ics/.Radicale.props
-> somehow not expected, I would suggest rejecting creation of entries in a folder in case this is not explicitly defined in .Radicale.props as VCALENDAR or VADRESSBOOK.

Permissions of 777 are probably the result of umask(0), see #540

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Sep 14, 2016

Member

new calendar entries are created as folders

It's normal. There's no difference between an event and a calendar in iCal, so PUTting an event in a non-calendar collection is just like creating a calendar in this collection. Nothing strange here 😉.

migration from old multi-filesystem one should perhaps document that calender "folder" layout changed

Of course! We just need to write the Storage page of the new configuration.

Dropping Phyton 2.x support and enforcing Phyton 3.x leads to installation problems on Enterprise Linux version 7 (latest RHEL or CentOS).

With "serious" distributions, it's probably not a good idea to use Radicale 2 before it's been officially packaged. But if anybody wants to try, using pip to install vobject and putting Radicale behind nginx+uwsgi is a solution that should be available in any current distribution.

Member

liZe commented Sep 14, 2016

new calendar entries are created as folders

It's normal. There's no difference between an event and a calendar in iCal, so PUTting an event in a non-calendar collection is just like creating a calendar in this collection. Nothing strange here 😉.

migration from old multi-filesystem one should perhaps document that calender "folder" layout changed

Of course! We just need to write the Storage page of the new configuration.

Dropping Phyton 2.x support and enforcing Phyton 3.x leads to installation problems on Enterprise Linux version 7 (latest RHEL or CentOS).

With "serious" distributions, it's probably not a good idea to use Radicale 2 before it's been officially packaged. But if anybody wants to try, using pip to install vobject and putting Radicale behind nginx+uwsgi is a solution that should be available in any current distribution.

@pbiering

This comment has been minimized.

Show comment
Hide comment
@pbiering

pbiering Oct 15, 2016

Contributor

new calendar entries are created as folders

It's normal. There's no difference between an event and a calendar in iCal, so PUTting an event in a non-calendar collection is just like creating a calendar in this collection. Nothing strange here 😉

Can one implement a feature (perhaps optionally like "strict_subfolder_usage") to prevent creating Items in the root folder which aren't collections? Because this turns to totally strange situation:

WP run calendar autodiscovery and suddenly has more calendars, the original "folder-based" ones + for each new Item created in the root-folder...means calendars in WP are increasing over time...one per new Item created by a client which (for whatever reason) places entries in the / folder

Contributor

pbiering commented Oct 15, 2016

new calendar entries are created as folders

It's normal. There's no difference between an event and a calendar in iCal, so PUTting an event in a non-calendar collection is just like creating a calendar in this collection. Nothing strange here 😉

Can one implement a feature (perhaps optionally like "strict_subfolder_usage") to prevent creating Items in the root folder which aren't collections? Because this turns to totally strange situation:

WP run calendar autodiscovery and suddenly has more calendars, the original "folder-based" ones + for each new Item created in the root-folder...means calendars in WP are increasing over time...one per new Item created by a client which (for whatever reason) places entries in the / folder

@pbiering

This comment has been minimized.

Show comment
Hide comment
@pbiering

pbiering Nov 10, 2016

Contributor

Please take a look on my pull request on top of master, I would consider it as stable now, found no issues so far: #526

Contributor

pbiering commented Nov 10, 2016

Please take a look on my pull request on top of master, I would consider it as stable now, found no issues so far: #526

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Feb 28, 2017

Member

I'll release a beta version of 2.0.0 soon. The 2.0.0 milestone has some issues open, but some of them can wait after the beta is released.

The future documentation can be updated on the gh-pages branch, take a look if you're interested!

Member

liZe commented Feb 28, 2017

I'll release a beta version of 2.0.0 soon. The 2.0.0 milestone has some issues open, but some of them can wait after the beta is released.

The future documentation can be updated on the gh-pages branch, take a look if you're interested!

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Apr 15, 2017

Member

I have released 2.0.0rc1 on PyPI! The version is hidden but available.

There are lots of cool features waiting in some pull requests, but I find them a little bit too dangerous to merge them just now. 2.0.0 is working quite well right now, I'll only merge bugfixes before 2.0.0.

Please check that everything works for you!

Member

liZe commented Apr 15, 2017

I have released 2.0.0rc1 on PyPI! The version is hidden but available.

There are lots of cool features waiting in some pull requests, but I find them a little bit too dangerous to merge them just now. 2.0.0 is working quite well right now, I'll only merge bugfixes before 2.0.0.

Please check that everything works for you!

@klonos

This comment has been minimized.

Show comment
Hide comment
@klonos

klonos Apr 21, 2017

The version is hidden but available.

Can you please share the secret 😄 ...links to binaries would be awesome 😉

klonos commented Apr 21, 2017

The version is hidden but available.

Can you please share the secret 😄 ...links to binaries would be awesome 😉

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe May 23, 2017

Member

Please read carefully if you're interested in Radicale's future.

Now that #591 is (almost) fixed, I'll release 2.0.0 using the git master branch on Saturday or on Sunday this week.

I know: I'm late.

Before the release, I'd like you (@untitaker, @pbiering, @Unrud, and anyone interested of course) to help me solving a couple of problems:

What do you think about that?

Another important point: THANK YOU.

It's been a pleasure to merge your pull requests and discuss all these issues and feature requests. After 2.0.0 is released, it's time for Radicale to find new co-maintainers with superpowers. Radicale has become a lot bigger and powerful than it was before. There are really interesting pull requests waiting to be merged, but I can't find the time and the motivation to read, review and merge them anymore. Moreover, I've always loved really simple code with a small amount of features, and I think that Radicale now wants to include features that I'm not ready to clean, debug and maintain alone. Of course, I'll keep an eye on the project and tell what I think, but I'd like to give admin rights to the repository and to PyPI to some current contributors. If anyone is interested, just tell me!

💓

Member

liZe commented May 23, 2017

Please read carefully if you're interested in Radicale's future.

Now that #591 is (almost) fixed, I'll release 2.0.0 using the git master branch on Saturday or on Sunday this week.

I know: I'm late.

Before the release, I'd like you (@untitaker, @pbiering, @Unrud, and anyone interested of course) to help me solving a couple of problems:

What do you think about that?

Another important point: THANK YOU.

It's been a pleasure to merge your pull requests and discuss all these issues and feature requests. After 2.0.0 is released, it's time for Radicale to find new co-maintainers with superpowers. Radicale has become a lot bigger and powerful than it was before. There are really interesting pull requests waiting to be merged, but I can't find the time and the motivation to read, review and merge them anymore. Moreover, I've always loved really simple code with a small amount of features, and I think that Radicale now wants to include features that I'm not ready to clean, debug and maintain alone. Of course, I'll keep an eye on the project and tell what I think, but I'd like to give admin rights to the repository and to PyPI to some current contributors. If anyone is interested, just tell me!

💓

@Unrud

This comment has been minimized.

Show comment
Hide comment
@Unrud

Unrud May 25, 2017

Collaborator

I'll release 2.0.0 using the git master branch on Saturday or on Sunday

Before you do this, please cherry-pick fc05e55
(#598 is the same fix, but checking path.startswith(base_prefix) was forgotten). The SCRIPT_NAME environment variable is currently not working at all.

I propose to merge (or reject) #604 and #608 before the release. They are very small, but change the default configuration and behavior of the --config command line argument slightly. Therefore, they cannot be merged in a minor release later.

I think that all the other open pull requests don't change anything in a manner that is not backwards compatible.

There are lots of issues open about the documentation.

I started writing the documentation for 2.0.0 in #607 and created an easier way to upgrade from 1.x.x in #606.

it's time for Radicale to find new co-maintainers with superpowers.

I would be interested. I was thinking about forking Radicale anyway.

Collaborator

Unrud commented May 25, 2017

I'll release 2.0.0 using the git master branch on Saturday or on Sunday

Before you do this, please cherry-pick fc05e55
(#598 is the same fix, but checking path.startswith(base_prefix) was forgotten). The SCRIPT_NAME environment variable is currently not working at all.

I propose to merge (or reject) #604 and #608 before the release. They are very small, but change the default configuration and behavior of the --config command line argument slightly. Therefore, they cannot be merged in a minor release later.

I think that all the other open pull requests don't change anything in a manner that is not backwards compatible.

There are lots of issues open about the documentation.

I started writing the documentation for 2.0.0 in #607 and created an easier way to upgrade from 1.x.x in #606.

it's time for Radicale to find new co-maintainers with superpowers.

I would be interested. I was thinking about forking Radicale anyway.

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe May 26, 2017

Member

Before you do this, please cherry-pick fc05e55

It's done, thanks.

I propose to merge (or reject) #604 and #608 before the release.

I've merged both, better now than later.

I think that all the other open pull requests don't change anything in a manner that is not backwards compatible.

I'm a coward, some of them are too big for me 😉. I'd prefer to merge them in a future version.

I started writing the documentation for 2.0.0 in #607 and created an easier way to upgrade from 1.x.x in #606.

I've merged #606 and I'll merge #607 just before releasing 2.0.0. I'll release a new 1.1.x version too.

I would be interested. I was thinking about forking Radicale anyway.

Good news! I think that you have the skills and motivation to bring Radicale to a higher level. No need to fork then, here is a copy of the key 🔑.

Member

liZe commented May 26, 2017

Before you do this, please cherry-pick fc05e55

It's done, thanks.

I propose to merge (or reject) #604 and #608 before the release.

I've merged both, better now than later.

I think that all the other open pull requests don't change anything in a manner that is not backwards compatible.

I'm a coward, some of them are too big for me 😉. I'd prefer to merge them in a future version.

I started writing the documentation for 2.0.0 in #607 and created an easier way to upgrade from 1.x.x in #606.

I've merged #606 and I'll merge #607 just before releasing 2.0.0. I'll release a new 1.1.x version too.

I would be interested. I was thinking about forking Radicale anyway.

Good news! I think that you have the skills and motivation to bring Radicale to a higher level. No need to fork then, here is a copy of the key 🔑.

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe May 27, 2017

Member

Radicale 2.0.0 has been released 🎉.

Member

liZe commented May 27, 2017

Radicale 2.0.0 has been released 🎉.

@liZe liZe closed this May 27, 2017

@djmattyg007

This comment has been minimized.

Show comment
Hide comment
@djmattyg007

djmattyg007 Jul 25, 2017

Congratulations :)

djmattyg007 commented Jul 25, 2017

Congratulations :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment