search

backdrop-ops / backdropcms.org

Issue tracker for the BackdropCMS.org website
https://backdropcms.org
25 stars 20 forks source link

Make developer (dev) releases available on backdropcms.org #236

Open quicksketch opened 8 years ago

quicksketch commented 8 years ago

Right now we have "dev" releases available from GitHub by downloading the most recent zip file at the top of the source code tree:

selection_129

However these dev releases are not available from backdropcms.org (thus project browser or update module). It would be nice if we could find a way to support these -dev releases on BackdropCMS.org.

quicksketch commented 8 years ago

The current challenges with this include:

klonos commented 8 years ago

A huge :+1: from me! I've long wanted to have official, versioned dev releases (https://github.com/backdrop/backdrop-issues/issues/664).

klonos commented 8 years ago

I just saw that @docwilmot made two initial releases for https://github.com/backdrop-contrib/tag and https://github.com/backdrop-contrib/autotag and named them 1.x-1.x and it just gave me an idea...

Could we react on each commit and automatically create a release with the same name as the branch name to which the commit was made to (1.x-1.x for example)? If a release with the same name already exists, then we first delete the old one and create a new one in its place (with the same version). This way we:

Thoughts?

jenlampton commented 8 years ago

We don't want dev releases showing up on the modules page or on on backdropcms.org. The reason we don't want people to be able to download them from our site, or install them using the project browser, is because the people who are likely to use a User Interface to install untested code are the people who are least likely to be able to fix their sites after they explode from putting a dev module on it.

These projects are -dev for a reason. You should be a developer to use them -- or at least understand the risks. Most developers or risk-takers will be able to download a .zip of the project they need, and they will also be able to find an delete that code if there is a catastrophic problem.

For someone who uses the UI to install a -dev project and has a catastrophic problem, they may not even know where the dangerous code was placed, or where/how to remove it.

What is the use-case for having support via project browser or update module? I think I may be missing the point here.

biolithic commented 8 years ago

I think this is a big UX win for Backdrop in not having dev releases. It's quite OK to experiment with code on repos and such but hopefully everything on bd.org works well.

klonos commented 8 years ago

We don't want dev releases showing up on the modules page on backdropcms.org. We don't want people to be able to download them from our site, or install them using project browser. They are -dev for a reason (you should be a developer to use them) and they should not be available via these UI tools for non-developers.

I strongly disagree there with you @jenlampton. If we "hide" dev releases and make them available only to the "elite" of developers and git command geeks, then we deprive project developers from a considerable amount of real-world, everyday people that are willing to test new features and/or fixes that have not yet made it to the official release. This means that official releases will most likely get less testing before made available. It's as plain as this: testing takes time and energy and as you mention is risky. If we add more difficulty on top of that (having people learn how to use git and GitHub), then people will simply not be bothered to test any more.

Also, gathering usage stats for dev releases is a very useful tool for project developers when it comes to deciding when to release: when their dev releases gather enough users, it means it's ready for official release.

In the Drupal contrib queues, we'd often hear this dialog:

When is this fix/feature going to be released? Don't know, but you can try the dev release that includes it!

Now, I realize that these type of answers urge people to use something that might prove risky, but instead of angry users that were given no solution besides having to wait (sometimes for years too), you had people that have been warned and then decided to take the risk in order to get their task done. So basically:

Slightly reluctant users that achieve what they want with the platform vs angry and frustrated people that think that things are "never" done and that Drupal/Backdrop sucks big time.

klonos commented 8 years ago

Disclaimer: this comes from a person that is an issue-queue dweller and that uses dev versions of projects were available instead of their respective stable releases. I have been doing that with production Drupal sites since 2007 and none of them broke in any unrecoverable way. Only a few WSODs and perhaps the occasional fatal error that made me revert to the previous dev after reporting it to the developer.

klonos commented 8 years ago

...don't forget that there are people out there doing the same thing for Backdrop as they are doing for D8: they are checking every now and then to see if their D7 contrib modules have been ported in order to make a decision. So having them as beta/dev is better in that we communicate to people that there is some work that has started on them. For example, @serundeputy in https://github.com/backdrop/backdrop-issues/issues/1944#issuecomment-224479794 just made available his port of https://github.com/backdrop-contrib/title but for non-GitHub users, there is absolutely no way to know anything about this fact.

biolithic commented 8 years ago

I also use dev releases of modules but I feel that this is a flaw with the Drupal community (but there are many positives with the Drupal community too). I like that with Backdrop you can say, "This is a working release of the module" or for example, "There is a non-working port of the Charts module" and let that be that. There isn't any grey area, where we say, "Yea, this dev release works perfectly...but nobody can make it version 7.2 or whatever. It's always going to be 7.x-dev, no matter!" I feel this confuses people to have a bunch of dev versions that work great, but maybe a couple dev versions that break things. Or possibly some features don't work?

klonos commented 8 years ago

...which brings me to https://github.com/backdrop-ops/backdropcms.org/issues/259 and https://github.com/backdrop-ops/contrib/issues/164 that I've been meaning to file for some time now (ever since I've come across https://www.drupal.org/project/contrib_tracker).

docwilmot commented 8 years ago

@quicksketch: Right now we have "dev" releases available from GitHub by downloading the most recent zip file at the top of the source code tree:

This may not be so simple; if a project has multiple test/dev branches how would GitHub API know which one to call the dev?

BUT if a user did in fact download and install a dev version, whatever that is, it would still be best if Backdrop and Update module could be able track updates of the installed dev, since there may be a risk with unupdated dev releases too. And then if Update supports this, then there isn't much point keeping it off Installer.

But I really don't see how Update module can track these updates in our current arrangement. There would be no versioning of the dev packages.

So in summary, I'm for including devs if it actually is possible

klonos commented 8 years ago

@docwilmot I don't think that dev versions should be actual builds in the same manner as we have release tags. For us, the dev would be the latest .zip available for example under https://github.com/backdrop/backdrop/archive/1.x.zip and its version would be 1.x-ea4e4b6 (append the latest commit label which is actually the 6 first characters of the commit SHA value).

Now, because commit SHAs are random and thus not sortable, we'd have to use commit times for figuring out which commit is newer.

If people wanted to test a specific dev, they could download the respective archive which for example for dev 1.x-50d9519 would be under https://github.com/backdrop/backdrop/archive/50d9519583ffa96eafbf18c427cd97c4c4134bd0.zip

Not sure how we could handle multiple dev branches, but I think we can since there are "trees" of commits:

https://github.com/backdrop/backdrop/commits/1.x https://github.com/backdrop/backdrop/commits/1.3.x

...and once we have a 2.x branch, there will be:

https://github.com/backdrop/backdrop/commits/2.x

klonos commented 8 years ago

...so basically, in d.org we had only a single dev for each branch because they were actual builds. So how it worked was that each time a new dev was built, it would override the old one. But with GitHub, we can have dev history and people will be able to revert to previous devs (whereas in Drupal personally, I had to keep local copies of dev archives by appending dates in the filenames).

klonos commented 8 years ago

..."There is a non-working port of the Charts module" and let that be that.

But nobody would be willing to test it if you called it a "non-working" port. If it was a dev version (which implies pre-alpha/pre-beta), people might be willing to test.

docwilmot commented 8 years ago

Difficulty there @klonos is there isn't necessarily a ...1.x.zip. If you check, some of the default repository branches are called "master", mine are usually called "1.x", some have "1.x-1.x". And thats just the default. Releases can be built off any branch. So if I had a "1.x", a "1.x-new", and a "doesnt-really-work" branch I could be building my releases off "1.x-new" even if its not default and the "1.x" branch could be absolute rubbish but still be there because I didnt bother to delete it. In which case the ..1.x.zip "dev" you pull would also be rubbish.

klonos commented 8 years ago

@docwilmot yes, I get that, but if people tested it and saw that it was no good, they'd report to the issue queue and get you to delete the branch you forgot to remove. ...or at least change the default branch from your repo settings page. Right?

The thing is that we cannot have multiple "active" brunches. So, if 2.x is released, you'd have to make that the default branch and then it wouldn't be that easy to get the 1.x dev releases.

klonos commented 8 years ago

...I see what you are saying though about 1.x vs 1.x-1.x vs master. Can't think of a way to tackle this unless we "enforce" versioning standards.

jenlampton commented 8 years ago

Here's what we DON'T want:

A developer decides they want to port the media module to backdrop. They get started, then get distracted, but put their code into the contrib group for someone else to finish. The module has never even been enabled on a backdrop site, but the code has been placed into the contrib group. (How most ports begin!) Yay, collaboration!

Then, someone unfamiliar with Backdrop sets up a site, goes to the project browser, searches for "media", sees a project, and clicks install. Then their site goes white-screen with no way for them to get it back because they have no knowledge of how to do anything without the UI, and now the UI is gone.

The initial impression that person gets is that backdrop is a complete piece of crap. This is because they never left the Backdrop UI, they don't know what a module is, or understand the risks they just took. All this person did is clicked a button, and they lost everything by doing so. This problem module appeared in a list of things to install, thus, it surely should be safe to install! It doesn't even really matter what we call it, dev only gains meaning with experience.

There is no good reason to allow untested modules (not tagged by their maintainers), to appear in a UI where people who don't even know what a module is are going to be able to shoot their site in the foot with it.

If a maintainer wants to 'release' a dev version then they can do that. They create a tag like 1.x-1.0.0-dev or -alpha or -beta or whatever they want, and voila. We get packaging, we get a node on backdropcms.org, we get a version in the project browser, and it's "safe".

We have similar hurdles in Drupal, maintainers have to actually state when a module gets a visible -dev release. We absolutely should not remove that protection from backdrop, where we are targeting a less technical user-base.

@klonos you are a very experienced site-builder and know what a dev version means, as well as how to recover your site from a WSOD if the user-interface is down. That means that I care about your needs less than I care about that poor first-time user mentioned above (sorry!). I'm much more concerned about protecting the experiences of all the people who know none of this (yet). If we want to keep them around, we need to not scare them away immediately.

But nobody would be willing to test it if you called it a "non-working" port. If it was a dev version (which implies pre-alpha/pre-beta), people might be willing to test.

But a dev version could be either of those things, and users won't know the difference. People might think dev means "needs testing" when it really means "I just played with this one weekend and never got it working". The maintainer should be required to do something (like tagging a release) when a module actually needs testing or is ready to be used on a site. We need to rely on the maintainers to make this call, and not put the burden of making that decision on the end user.

Putting every module in every state of development into the project browser is a recipe for disaster. </rant>.

Can't think of a way to tackle this unless we "enforce" versioning standards.

We kind of do this already. The packager only works if the versioning is correct.

stpaultim commented 2 years ago

I agree with @jenlampton about what we don't want. However, I am inclined to think that our thinking MIGHT have changed slightly in that while we DON'T want to make it easy to install a unfinished module we MIGHT want to make it easier to discover an unfinished module/port.

During the last Backdrop LIVE there was a fair amount of discussion about the fact that folks evaluating Backdrop might be looking for and basing their decisions on specific module that they think they really need. They check on BackdropCMS.org or in the project installer and don't see those modules, so they assume that they are completely NOT available or that no work has been done on them and proceed to look for other solutions.

In fact, we have very popular modules such as Organic Groups and Display Suites for which ports are underway and work has been completed, but someone evaluating Backdrop might not find them. It's not uncommon for someone to complain that a Drupal 7 module is not available, until someone with more experience points out that in fact the module IS available in backdrop-contrib, but simply does not have a release. Sometimes, it's a completely working version that simply has not been sufficiently tested.

I think the goal is to balance these two competing goals:

1) To make it easier for new folks or folks evaluating Backdrop to find dev modules and potentially help bring them to completion or release. AND 2) To avoid anything that encourages folks with limited experience to install a dev module on their production site and potentially break their site, without understanding the risk and/or the path to recovery.

Is this the right issue to talk about this balance OR do we need a new issue?

bugfolder commented 2 years ago

One possible way of striking that balance would be to list anything that's in backdrop-contrib on b.org in the project listings, but instead of showing a release download, show something like "In Development" with a link to the Github repository. That makes it clear that it's not an official release, but that there's something in progress, and then those who know what they're getting into could download from Github to try it out.

albanycomputers commented 2 years ago

The .info file could also be used to display the status of a release.

Issue... "Add more properties to module and theme info files... Initial Release date, Current Release Date, Categories, D7 base module or theme if any #5367 " https://github.com/backdrop/backdrop-issues/issues/5367

kiamlaluno commented 1 month ago

My experience with development snapshots on drupal.org is that they should not be used from people who just need the module features in a site, but do not contribute to fix bugs or improve the module code. Often, people use a development snapshot because a bug they noticed in their site has been fixed, but they "forget" development snapshots are WIP. I would rather not show development snapshots in a project browser.

izmeez commented 4 weeks ago

It may help to clarify what it means to use a dev code base. There may be more than one reason or meaning and while desiring feedback is a coder's delight it may not be in the user's repertoire. To add to the discussion, users may need to use a dev version because it includes commits to address some issues not addressed in the tagged release. Drupal had/has a huge time lag to the date of tagged releases and drupal contrib modules can be even more notorious.

With Backdrop core, one might say the time lag is not a concern, but with contrib it may be. Using a dev package with commits is something users could learn to do much easier than learning to manage and apply patches and may be sufficient for many use cases.